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1. Field of Invention 

Public key encryption with large key sizes (e.g. . RS A) is usually required 
for creating acceptable levels of security for message processing over an insecure 
network, such as the Internet. The present invention relates to a method for increasing 
the efficiency of secure message processing over such insecure networks. More 
specifically, the present invention relates to a method for reducing the level of 
encryption required in a network for message exchanges. Even more specifically, the 
present invention relates to processing electronic cash transactions in a secure manner 
while substantially reducing the computational requirements for encryption. 

2. D^scriptipn of thi? ftrior Art 

Various methods for increasing the security of communications over 
insecure networks, such as the Internet, have been disclosed. An insecure network does 
not protect messages from observation, interception, and manipulation. On the other 
hand, secure networks offer various means to reduce the opportunity for observation, 
interc^tion, and/or manipulation of messages. 

For example, chaxmel message security schemes (such as secure HTTP 
("S-HTTP") and Secure Socket Layer (SSL) protocol) are intended to create confidence 
in two communicating parties that they are who they say they are and that their 
communications are private. SSL utilizes digitally signed certificates to provide 
authentication and security by heavily encrypting each message. S-HTTP relies on 
digitally signed messages using a heavy encryption key to ensure security and 
auAentication. 

A number of multi-party protocols have been proposed for credit 
transactions, most notably Secure Transport Technology (STT), Internet Keyed Payments 
(IKP), ami Secure Electronic Payment Protocol (SEPP). All of these approaches are 
built around a credential issuing auAority and require that both merchants and customers 
be authenticated by the credential issuing authority which in turn has been authenticated 
by a higher audiority. In STT, merchants and customers each have two sets of RSA of 
keys, one to be used to sign messages and one used to encrypt and decrypt symmetrical 
keys. Thus, in this system, each party needs two certificates (one for each key). A 
merchant will have a pair of credentials for each credit card it accepts. SEPP and IKP 



use RSA encryption differently; but, like STT, utilize multiple public key signatures and 
encryptions per transaction. 

Another system has been described under the name "NetBill.** While the 
NetBill approach is less reliant on public key encryption than others, it still requires 
5 public key signaoires throughout a transaction. 

Another approach is that of DigiCash. In the DigiCash model, the user 
creates a random number, which acts like a serial number for a digital coin. Like the 
other proposed systems, DigiCash achieves its primary objective of a secure, anonymous 
cash payment system by requiring heavy reliance on modular ejq)onentiation (which is 
10 the basis for other public key techniques such as RSA encryption). It also requires a 
bank or third party to create tokens that have intrinsic value. It is uncertain how such 
a system will be treated under banking, tax, and currency laws in the United States and 
other jurisdiction. 

Other systems, such as Mondex, implement security through the use of 
15 hardware connected to tte user's computer. For Internet transactions, a proprietary card 
reader must be added to the computers of all customers and merchants who will use a 
particular card. 

The reliance on encryption, especially public key encryption, whether 
based in software or hardware comes at a price: the greater the use of encryption, the 
20 greater die processixig effort required to decrypt inessages. Where message processing 
costs are importaitt, such as in commercial network payment tran^ction, processor and 
hardware costs can become a significant deterrent to using n^orks such as the Internet 
for secure communications. 

The current art can only achieve acceptable security with the concomitant 
25 highcostof processor time, additional hardware, or both. What is needed to encourage 
die development of insecure networks such as the Internet fc^ commercial use is a 
software-based system that offers reduced processing costs of encrypted messages while 
mflinfainiTig an acceptable level of security for the communications being transmitted. 

Si;MMARYOyiNVENTi^^ 

30 Therefore, the present invention aims to provkie a method for very 

efficient, economic aid secure transactions over the Internet, or c^faer insecure networks . 
This provides the basis for implementing relatively small vahie, secure payment 
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(including smaU cash payments) for products over the Internet or other insecure 
netwoiks. 

In accordance with an aspect of the present invention, there is provided 
a method for securely communicating in a communication system, wherein the 
communication system has a device at a user's location and a server in communication 
therewith, wherein the metfiod comprises transmitting a request from the device to the 
server for creating a session having use parameters associated dierewith. encrypting a 
first key with a second key by die server, transmitting said encrypted first key and said 
use parameters associated witii said session from the server to die device, receiving said 
enciypted first key and said use parameters by die device and decrypting said encrypted 
first key so that die device can communicate securely in die communication system by 
using said decrypted first key according to said use parameters. 



BRIEF DRSntTPTinhr PHAWTMnS 
15 Representative embodiments of die present invention will be described widi 

reference to the following drawings- 

Figure 1 depicts die general architecture of die present invention. 
Figure 2 depicts die general processes of die present invention, 

2 0 Figure 3A more particularly depicts die processes shown in Figure 2, 
Figure 3B depicts die flow of messages in die present invention. 
Figure 4A depicts die stiwcture of die database of die server counter 100, 
Figure 4B depicts a customer persona 120.1 of server persona data structure 120, 
Figure 4C depicts die fields of cash container data 120G of Figure 4B, 

25 Figure 4D depicts die fields of instniment bindmg data 120H of Figure 4B, 

Figure 4E depicts a merchant persona 120.2 of server persona data structure 120. 
Figure 4F depicts die fieUs of cash container data 120GG of Figure 4E, 
Figure 4G depicts die fields of instniment bmding data 120HH of Figure 4E, 
Figure 4H depicts customer session record 130.1 of server session data stiurture 130. 

» 0 Figure 41 dq>icts die fields of transaction data 130N of Figure 4H. 

Figure 4J depicts merchant session record 130.2 of server session data strucmre 130. 
Figure 4K dqiicts dtt fields of transaction data 130NN of Figure 41, 
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Figure 4L depicts a record 140.1 of message log data structure 140, 
Figure 5A depicts the structure of the database of the customer computer 200, 
Figure SB depicts record 215.1 of customer application data structure 215, 
Figure 5C depicts record 220.1 of customer persona data structure 220, 
5 Figure 5D depicts record 230.1 of customer instrument binding data structtire 230, 
Figure 5E depicts record 240.1 of customer active session data structure 240, 
Figure 5F depicts customer pending log data structure 2S0, 

Figure 5G depicts pending regismuion/update persona information record 251 of 
customer pending transaction data stnicoire 250, 
10 Figure 5H depicts pending link/update instrument binding record 2S2 of customer 
pending transaction data structure 250, 

Figure 51 depicts pending cash payment record 253 of customer pending transaction data 
^ructure 250, 

Figure 5 J depicts pending load/unload funds record 254 of customer pending transaction 
15 data structure 250, 

Figure 5K depicts penduig(^)en session record 255 of customer pending transaction data 
structure 250, 

Figure 5L depicts pendmg close session record 256 of customer pending transaction data 
structure 250, 

20 Figure 5M depicts customer log data structure 260, 

Figure 5N depicts persona registration/update response record 261 of customer log data 
strucmre 260, 

Figure 50 depicts link/iqxlate instrument req)onse record 262 of customer log data 
structure 260, 

25 Figure 5P depicts cash paymrat response record 263 of customer log data structure 260, 
Figure 5Q depicts loadAmload funds response record 264 of customer log data structure 
260, 

Figure 5R dqncts open session response record 265 of customer log data structure 260, 
Figure 5S depicts payment request record 266 of customer log data strucmre 260, 
30 Figure 5T depicts close session response record 267 of customer log data structure 260, 
Figure 5U depicts a record 280.1 of Customer cash container data structure 280, 
Figure 6A depicts the structure of the database of die merchant conqniter. 
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Figure 6B depicts a record of die merchant application data structure of the database of 
the merchant computer. 

Figure 6C depicts a record of the merchant persona data structure of the database of the 
merchant computer, 

5 Figure 6D depicts a record of the merchant instnmient binding data structure of the 
database of the merchant computer, 

Figure 6E depicts a record of the merchant session data structure of the database of the 
merchant computer. 

Figure 6F depicts a record of the merchant cash container data structure of the database 
10 of the merchant computer. 

Figure 7A depicts a record of the merchant amount data structure of the database of the 
merchant computer. 

Figure 7B depicts a record of the merchant sales session data structure of the database 
of the merchant con4)uter, 
15 Figure 7C depicts a record of the merchant cash log data structure of the database of the 
merchant computer. 

Figure 7D depicts the format of a sample n^ssage. 
Figure 8 is a flow diagram tUustradi^ registration process 401, 
Figure 9 is a flow diagram iUustrating message assembly procedure 800, 
20 Figures lOA and lOB iiepkt die format of registration message Rl, 

Figures UA and UB is a flow diagram illustrating server message unwrap procedure 
900, 

Figure 12 is a flow dis^ram illustrating server n^ssage assembly procedure 1000, 
Figures 13A and 13B depia the format of registration message R2, 

25 Figure 14 is a flow diagram ilhistrating client niessage unwr^ procedure 
Figure 15 is a flow diagram illustrating mstrument binding process 403, 
Figures 16A and 16B depict the format of binding message BIl, 
Figures 17A axKl 17B depict the format of binding m^sage BI4, 
Figure 18 is a flow diagram iUustiating the load/unload funds process 405, 

30 Figures 19A aixl 19B depict die format of load/unload message LUl, 
Figures 20A and 20B depict tte format of load/unload message LU2, 
Figure 21 is a flow diagram illustrating open session process 407, 
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Figures 22A and 22B depict the format of open session message OSl, 

Figure 23A and 23B depict the format of open session message 0S2, 

Figures 24A, 24B and 24C depict a flow diagram illustrating transaction/paymem 

process 409, 

5 Figure 25 depicts the format of payment request message PRl, 

Figure 26 depicts a flow diagram illustrating message unwrap procedure 3300, 
Figure 27 depicts a flow diagram illustrating message assembly procedure CA12, 
Figures 28A and B depict the format of cash payment message CAl, 
Figure 29 depicts a flow diagram illustrating CA-DES-key generation process 1600, 
10 Figure 30 depicts a flow diagram illustrating message unwr^ procedure CAl, 
Figures 31A, 31B and 31C dqpict the format of message CA2, 
Figures 32A and 32B depict a flow diagram illustrating server message unwrap 
procedure 1660, 

Figure 33 depicts a flow diagram illustrating server message assembly procedure 3400, 

15 Figure 34A, 34B and 34C depict the format of message CA3, 

Figure 35 depicts a flow diagram iUustrating message unwr^ procedure CA34, 
Figure 36 depicts a flow diagram iUustrating message assembly procedure 3100, 
Figures 37A and 37B depia the format of message CA4, 
Figure 38 depicts a flow diagram illustrating close session process 411, 

20 Figures 39A and 39B depict the format of message CSl, and 
Figures 40A and 40B depict the format of message CS2. 

l>li;7-An.im ra^rglPnON OF THE PREFERRED EMBODIMENTS 

Reference is now made to Figures 1^ for the purpose of describing, in 
25 detail, the preferred embodiments of die present invention. The Figures and 
accompanying detailed description are not intended to limit the scope of the present 
invention. 

I. Inf ormatia q Af^l^ Inf ormation Flow 

The present invention is generally depicted in Figure 1. Figure 1 shows 
30 three entities: server conqniter 100, customer computer 200 and merchant computer 
300, connected to each other via Ae Internet SO. The connecdons are identified by lines 
105, 205 and 305, respectively. 
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Customer computer 200 represents the computer of an individual^ 
customer user 203, who wants to buy a product over the Internet 50. (A "product" 
includes goods, services, information, data, and the like). Customer computer 200 
includes customer database 202 and customer application software 210. Merchant 
5 computer 300 represents the computer of an individual, merchant user 303, who 
provides the product to customer user 203 over the Internet 50. Merchant computer 300 
includes merchant database 302 and merchant application software 310. Information 
relating to merchant user 303 is stored widiin merchant database 302. Merchant 
application software 310 executes the processes of the present invention. 

1 0 While the following detailed descr^tion is provided for a single customer 

user 203 and a single merchant user 303, it is noted diat die present invention 
contemplates communication and transactions between both single and multiple customer 
users 203 and single and multiple merchant users 303. 

Server computer 100 communicates securely - as will be described in 

15 detail later - with customer computer 200 and merchant computer 300 over the Internet 
50 to effect transactions between customer user 203 and merchant user 303. Server 
computer 100 inchides server database 102 and server software 110. Information 
relating to server computer 100, customer user 203 and merchant user 303 is stored 
within server database 102. Server software 110 executes the processes of the present 

20 invention. 

Communication between server con^niter 100, customer computer 200 and 
merchant computer 300 is prefmbly carried out by hypertext transport protocol 
("HTTP") over the World Wide Web ("WWW") services provided on die Internet 50. 
Of course, other protocols and networks may be used or desired. 
2 5 Figure 2 depicts the general processes perfonned by die present mvention. 

The processes start at step 0. 

Preliminarily, setup processes are performed at step 1. In the semp 
processes, customer user 203 and merchant user 303 (collectively "clients" ) are 
configured widiin database 102 of server computer 100. In this manner, clients can be 
30 recogxiized by arid coixmiunicate widi server computer 100. Customer database 202 and 
merchant database 302 are also configured at stq) 1. 

An open session process is perfonned at step 2. Generally, a session is 
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an opportunity (or window) in which customer user 203 may purchase a product from 
merchant user 303 over the Interoet 50 or in which merchant user 303 may provide a 
product to customer user 203 over the Internet 50. Customer user 203 and merchant 
user 303 have their own independent sessions. Sessions are of limited duration. This 
duration is governed by parameters. These parameters are preferably set by customer 
user 203 and merchant user 303. Alternatively, server computer 100 may set such 
parameters. 

A transaction/payment process is performed at step 3. In this step, 
customer user 203 and merchant user 303 agree upon a product to be provided at an 
agreed upon price. Customer user 203 pays for the product with electronic cash. 
Electronic cash is a representation of funds (real cash, credit, etc.) used in the present 
invention. The electronic cash is received by merchant user 303 who can provide the 
purchased product to customer user 203 . Customer user 203 may conduct business with 
multiple merchant users 303 during a session. Customer user 203 and merchant user 
303 are only able to transact business for the duration of sessions such as those created 
at step 2. 

A close session process may be included in the present invention at step 
4. This step ends die session created at step 2. 

The processes performed by the present invention end at step 5. 

Referring to Figure 3 A, the processes described above in steps 1 through 
4 of Figure 2 are now more particularly described. Initially, the setup processes 
performed at step 1 inchide download and installation process 400, registration process 
401, instrument binding process 403 and loadAmload funds process 405. 

During the download and installation process 400, customer user 203 and 
merchant user 303 each download and install a copy of client application software 153 
(Figure 1) which preferably resi<tes on the Internet 50. Within customer computer 200 
and merchant conqniter 3(X), the copy of client application software 153 resides as 
customer application software 210 and merchant application software 310, respectively. 
(Merchant plication software 3 10 includes other software to enable merchant computer 
300 to perform the fimctions described below). Using well known techniques, customer 
application software 210 and merchant application software 310 are linked to the web 
browser of customer conqmter 200 and merchant computer 3(X), respectively, and are 



8 



15 



accessed through the browser as necessary. 

Next, at registration process 401, customer user 203 and merchant user 
303 register with server computer 100. That is, "persona" for customer user 203 and 
mercham users 303 is created within database 102 of server computer 100. A "persona" 
5 is herein defined as a collection of data relating to a specific diem. Therefore, by this 
registration process, each customer user 203 and merchant user 303 who has registered 
with server computer 100 has their own persona in server computer 100. (The deuUs 
of personas wiU be described later). The right of a persona to perform certain operations 
(e^. load funds, unload flmds. submit certain messages to server computer 100) may 
10 be enabled or disabled on a message or service basis. 

During the instrument binding process 403 of Figure 3A, a cUem (a 
customer user 203 or a merchant user 303) communicates information to server 
computer 100 which it uses to establish that the cUem may use a financial instrument. 
Financial instruments may inchide credit cards, debit cards, demand deposit accounts 
("DDAs") or other financial instruments. The issuer of the instrument bemg bound or 
a tilird party guarantor sets whatever criteria are deemed necessary by it to determine 
ifthecUentmayusetheinstrumem. For example, a bank issuing a credit card may find 
sufficient that the client provide a five digit postal code and his mother's maiden name 
in order tousediecredit card. Alist of these criteria may. for example, be provided 
to server computer 100 in which case server computer 100 can communicate with the 
client to establish whether the client meets these criteria so that the cUem can use the 
financial instnunent. 

Once the client establishes that the client may use the instroment by diis 
process, die instrument is "bound" to or associated with the client's persona created 
during registration process 401. Once the instnmient is bound, the cliem can use the 
instrumem for transactions as will be described later. 

LoadAmload funds process 405 is discussed next. For customer user 203, 
a "load" is the process by which funds associated with a bound instrument are "loaded" 
(or transferred) to the persona of customer user 203. In the persona of customer user 
3 0 203, the funds are represented as electronic cash. For customer user 203, an "unload" 
is die process by which electronic cash is "unloaded" (or transferred) from the persona 
of customer user 203 to a bound instrument. Formerchant user 303, an "unload" is the 
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process by which electronic cash is "unloaded' from the persona of merchant user 303 
to a bound instrument. For merchant user 303, a "load" is the process by which funds 
associated with a bound instrument are "loaded" to the persona of merchant user 303. 
In the persona of merchant user 303, the funds are represented as electronic cash. 
5 The open session process described for step 2 m Figure 2 is further 

explained with regard to the open session process 407 of Figure 3A. When customer 
user 203 creates a session, customer user 203 is enabled to transact business over the 
Internet 50 with one or more merchant users 303 who have each created their own 
independent sessions. (Of course, merchant users 303 may also act as customer users 

10 203 if they so desire.) 

The transaction/payment process 409 is performed next. During this 
process, customer user 203 and merchant user 303 may negotiate and agree upon the 
elements of a transaction (e.g.. a particular product and price). Then, merchaiu user 
303 may request that customer user 203 pay the agreed upon price for the product. In 

15 response to the request of n»chant user 303« customer user 203 may communicate to 
merchant user 303 that customer user 203 accepts the agreed iq>on price for the product. 
It is preferred that merchant user 303 cause information regarding the transaction to be 
submitted to server conqmter 100 for validatioiL If server computer 100 validates the 
transaction, electronic cash is transferred from the persona of customer user 203 to the 

20 persona of merchant user 303. Once notified of validation, merchant user 303 can 
provide the product to customer user 203. 

At close session process 411, die session created during open session 
process 407 may be terminated. When customer user 203 (or merchant user 303) closes 
the session, server computer 100 disables customer user 203 (or menAant user 303) 

25 from transacting business over the Internet SO with another merchant user 303 (or 
customer user 203) who has an open session unless customer user 203 has other open 
sessions. 

Referring to Figure 3B which depicts the flow of messages of die present 
invention, registration process 401 is carried out by customer computer 200 sending 
30 message Rl ("Registration 1") to server computer 100. In re^xmse to message Rl, 
server conqputer 100 sends message R2 ("Registration 2") back to customer computer 
200. The information included in these registration messages will be described later. 
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During instrument binding process 403, customer cooqniter 200 sends 
message BIl ("Bind Instrument 1") to server computer 100. The information in message 
BIl is used by server computer 100 to confinn the authority of the binder of the 
instrument with the issuer of that instnunent or a third party guarantor. The 
5 confirmation process could also be augmented by the exchange of messages (herein, 
messages BI2 and BD) between server computer 100 and customer computer 200. In 
this instance messages BI2 and BD woild have a fonnat similar to that of the other 
messages described herein. The content of message BI2 may include requests for 
additional infoimation (prompted by the issuer of the instrument) or clarification of 
10 infoimation as required by the issuer of the instrument or die third party guarantor. For 
example, message BI2 may cause customer user 203 to be prompted for customer user 
203 *s mother's maiden name. Message BD may contain the response of customer user 
203. 

In response to message BIl, server computer 100 sends message BI4 
15 ("Bind Instnmient 4") back to cu^omer computer 200. The information included in 
these binding messages will be described later. In die descrq)tion which follows, 
messages BIl and BI4 are the apcrasivc messages for uistrument binding. 

During load/unload funds process 405, customer computer 200 sends 
message LUl ("Load/Unload V) to server conqxiter 100. In response to message LUl, 
2 0 server conq)Uter 100 sends message LU2 ("Load/Unload 2-) back to customer computer 
200. The information included in these load/unload fimds messages will be described 
later. 

During open session process 407 customer computer 200 sends message 
OSl ("Open Session 1") to server computer 100. In response to message OSl, server 

25 computer 100 sends message 0S2 ("Open Session 2") back to customer computer 200. 
Tbt information included in these open session messages will be described later. 

During transaction/payment process 409, merchant computer 300 sends 
message PRl ("Payment Request 1") to custonwr computer 200. In response to message 
PRl. customer cortputer sends back message CAl ("CAsh payment 1") to merchant 

30 computer 300. After receiving message CAl, merchant coniputer sends message CA2 
("CAsh payment 2") server computer 100. In response to message CA2, server 
computer 100 sends back message CA3 ("CAsh payment 3") to merchant computer 300. 
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In response to message CA3, metcbant computer 200 sends message CA4 ("CAsh 
payment 4") to customer computer 200. The information inchided in these 
transaction/payment messages will be described later. 

Durii^ optional close session process 411, customer computer 200 sends 
5 message CSl ("Close Session 1") to server computer 100. In response to message CSl, 
server computer 100 sends message CS2 ("Close Session 2") to customer computer 200. 
The information included in these close session messages will be described later. 

It is noted that Figure 3B depicts messages R1/R2, BI1/BI4, LU1/LU2. 
0S1/0S2 and CS1/CS2 passing between customer computer 200 and server computer 
10 100. Merchant user 303 causes d>ese same messages to flow between merchant 
computer 300 and server computer 100. It follows that merchant user 303 executes 
registration process 401, instrument binding process 403, load/unload funds process 405, 
open session process 407 and close session process 411 in the same way as customer 
user 203, unless otherwise noted. In the case of merchant user 303, data associated with 
15 these processes is manqmlated with regard to the merchant database and merchant data 
structures incltided in server computer 100. 

The databases and data structures used in the preferred embodiments of 
the present invention are described next, 
n. Databases 

2 0 Referring to Figure 1, server computer 100, customer computer 200, and 

merchant computer 300 inchide databases 102, 202 and 302, respectively. While the 
following description of databases 102, 202 and 302 refer to specific data structures and 
formats, those skilled in the art will readily q>preciate that such specific data structures 
and formats are not critical to and are not considered part of the present invention. 
25 Therefore* any modifications to the data stnictures and formats would be within the 
scope of the appended claims. 

It is preferred that values be stored in databases 202 and 302 when a 
response message is received by customer computer 200 and merchant computer 300, 
respectively. However, where it enhances clarity, values are described as being stored 
30 prior to the receipt of such a response message. 
A. Sorer Database 102 

Server database 102 stores data enabling server computer 100 to 
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cammunicate with and process transactions between customer con^)iiter 200 and 
merchant computer 300. Figure 4A depicts the general structure of server database 102. 

As shown in Figure 4A, server database 102 includes server persona data 
structure 120, server session data strucnire 130. message log data structure 140, message 
5 data structure 150 and public key data strucmre 160 and application data structure 170. 
Each of these data structures is now described in detail. 

1. Server Persona Data Structure 120 

Server persona data strucmre 120 stores data relating to the universe of 
customer users 203 and merchant users 303 who have registered with server computer 
1 0 100, Referring to Figure 4B, persona data structure 120 includes one or more customer 
personas 120.1. It is preferred that customer persona 120.1 be recorded having fields 
120A-120H. Server persona data structure 120 contains a customer persona 120.1 for 
each registered customer user 203. The fields of customer persona 120.1 are now 
described. 

^5 Field 120A stores a persona id for customer user 203. The persona id 

identifies particular customer user 203, In order to increase system security, server 
database 102 does not store recognizable mformation for customer user 203. For 
example, the actual name aixi address of customer user 203 is not stored within server 
database 102. Rather, the pttsona id is used for identification. The persona id field is 

20 optional hi that die information stored in public key field 120C (described below) may 
also be used to locate records associated with customer user 203. Because a persona id 
is shorter than a public key it is more efficient, and thus preferred, to use die persona 
id for tfiis purpose. 

Field 120B contains an email address for customer user 203. Using the 

25 email address of field 120B, server computer 100 is able to send email to customer user 
203 over the Interna SO. 

Field 120C stores an RSA public key for customer persona 120.1. As is 
more fully described below, die RSA public key of field 120C is generated by customer 
application software 210, The RSA public key of field 120C is the public component 

30 of an RSA public/private key pair. Botfi the RSA pubUc and private key for a customer 
conqniter 200 are stored m customer conqmter 200, as described la» In the preferred 
embodiment, RSA keys are 768 bits in lengfli. This length reflects a balance between 
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increasing security (achieved using longer keys) and decreasing processing costs 
(achieved using shorter keys). As processor power increases in the future, longer RSA 
keys may be used to increase security without compromising system performance. 

If Che customer RSA public key is encapsulated in a certificate by 
5 appropriate certification authority, the key from the certificate is used in place of the 
public key and the persona id field 120A is no longer optional as previously described. 
Certificate based systems are well known in the art and are not described. 

The date that customer user 203 registered with server comimter 100 is 
stored in field 120D. The date of field 120D permits the running of promotions (e.g. , 
10 if you register before this date, then this will h^^pen) and assists in the resolution of 
disputes. 

Field 120E contains a preferred language of commimication for customer 

user 203. 

Field I20F stores an autoclose pasq)hrase for customer user 203. The 
15 autoclose passphrase is a passphrase which allows customer user 203 to close customer 
persona 120.1 in certain circumstances as described later. 

Data 120G represents a data structure containing fields 120G.1-120G.4, 
shown in Figure 4C. Fields 120G.1-120G.4 store data for each cash container 
established by customer user 203. Server persona data structure 120 contains a set of 
2 0 fields 120G. 1 -120G.4 for each cash container established by customer user 203. The 
cash container sums electronic cash. It is contemplated diat multiple cash containers 
can be used, e.g., one for each currency that customer user 203 intends to transact 
business in. 

Fields 120G.1-120G.4 are now described in detail widi reference to 
25 Figure 4C. 

Field 120G. 1 stores the currency associated with the amount of electronic 
funds stored in fields 120G.2 and/or 120G.3. 

Field 120G.2 stores the available-balance of the cash container. 
Field 120G.3 stores the on-hold-bahmce of the cash container. 
30 Electronic cash stored in fields 120G.2 and/or 120G.3 is preferably 

deposited into an agency account (a form of banking instrument in which funds are held 
by one party for the benefit of the other). The account number of this agency account 
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is stored in field 120G.4. 

Data 120H represents a data structure containing fields 120H. 1-120H.28. 
shown in Figure 4D. Fields 120H. 1-120H.28 store data for instiuments bound to 
customer persona 120.1. Server persona data structure 120 contains a set of fields 
120H.I-120H.28 for each instrument bound to a customer persona 120.1. Fields 120H.1- 
120H.28 are now described in detail wifli reference to Figure 4D. 

Field 120H.1 stores the persona id of field 120A (Figure 4B). The 
persona id of field 120H.1 indicates the persona 120.1 to which the instrument having 
data stored in fields 120H. 1-120H.28 is bound. 

Field 120H.2 contains an instrument type for the bound instrumem. 
Instrument types preferably inchide bank accounts, debit cards and credit cards. 

Field 120H.3 stores an instrument subtype for the bound mstnunent. The 
instrument subtype is a sub<lassification of an instrument type (e.g. . 'VISA* for the 
instrument type credit card"). 

Customer user 203 may elect to activate an "autoclose" feature when 
registering its persona 120. 1 . The autoclose feature permits customer user 203 to provide 
a passphrase (described later) to close customer persona 120.1 and to unload aU 
electronic cash associated witii that persona to an autoclose mstrument. If the instrument 
being bound is the autoclose instrument, field 120H.4 contains an instrument number for 
the bound mstrument. The instrument number identifies the instrument. It is preferred 
that the instrument number be encrypted before it is stored. Alternatively, the 
instrument number could be saved m a separate store device not connected to server 
computer 100. If the instrument being bound is not the autoclose instrument, the 
instrument number is used to compute field 120H.9 (as described later) and the 
instrument number is not stored in field 120H.4. 

Bound instruments may have a secondary number further identifying the 
bound instrument, for ^an^le. an American Ejqness CID or a US-DDA account R/T 
number. Such secomlary numbers, referred herein to as instrument sub-numbers, are 
stored in field 120H.S. 

Bank accounts are created in a single currency. The native currency of 
a bank accoum instrument is stored in field 120H.6. 

Field 120H.7 stores one or more integers representiiig legal agreements. 
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In the piefened embodiment, tbe operator of seiver computer 100 determines what legal 
agreements must be agreed to by customer user 203 in order for customer user 203 to 
use the bound instrument to perform certain operations. 

Field 120H.8 contains an instrument prefix. The instrument prefix of 
5 120H. 8 is subset of the instrument number described in reference to field 120H.4. In the 
preferred embodiment, the instrument prefix of field 120H.8 (for credit cards, debit 
cards, and bank accounts) is the first two aixi the last four digits of tbe instrument 
number of field 120H.4. 

Field 120H.9 stores an instrument hash value, preferably an MDS hash of 

10 tte instrument number described with reference to field 120H.4. (The term "hash" as 
used in this application refers to cryptogr^hic hashes, as opposed to other mathematical 
hashing functions such as algebraic hashes.) The instrument number represented by tbe 
hash is preferably made more difficult to guess by concatenating the instrument number 
with a random number generated and provided to server computer 100 by customer 

15 conqmter 200 (such number commonly referred to as a "salt") before hashing. The 
instrument salt is stored m field 230Q of customer instrument binding data structure 230 
as discussed below. The instrument hash of field 120H.9 is used to verify die 
instrument number without requiring the in^rument number to be stored at server 
compute 100. This reduces die attractiveness of server computer 100 as a target for 

20 thieves and scoundrels, 

Field 120H. 10 contains an identification number of the issuer of the boimd 
instrument, also known as a "BIN", or bank id number. 

If the instrument being bouixl is to be used as autoclc^ instrument, fiekls 
120H.1I and 120H.12 contain die name and address of a holder of the bound 

25 instrunmit. It is preferred that this information be encrypted before being stored. 
Alternatively* the instrument number could be saved in a separate store device not 
connected to server conqmter 100. 

Fields 120H.13 and 120H.14 store dates that tbe bound instrument was 
bound and was first used, respectively. 

30 Field 120H.1S contains a status of a bouiKl instrument. The conteitt of 

binding status field 120H.15 is dependent upon the instrument being bound. For 
example, to biixl a DDA, customer user 203 may be required to sign a form and 
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authorize the operator of server computer 100 to initiate a pre-notification ("pre-note") 
process with an automated clearing house ("ACH"). Before receiving the signed form 
or the response to the pre-note, server computer 100 may show that the binding was 
"created". Upon receiving the signed form, status field 120H. 15 may contain "pending 
5 pre-note". If the pre-note is sent before the signed form, field 120H.15 may contain 
"pending-signature" . If both have been received and are acceptable, field 120H. 15 may 
contain "enabled" . If there were a problem widi either, or if a specified time period for 
receiving either requirement expires, field 120H.15 may contain "disabled". Field 
120H.15 may also contain "disabled" if die instrument is subsequently determined not 
10 to be usable (e^, an account is frozen by a bank). The status of other bound 
instruments will depend on the instrument type and the steps necessary to bind a 
particular type of instrument. Of course, the prenote process may be performed on-line. 

Field 120H. 16 is a flag indicating whether the bound instrument is enabled 
for sale transactions. Asalc transaction is where customer persona 120.1 is used to pay 
15 for something using a bound instrument directly, as in the use of a debit card. 

If field 120H.16 indicates diat the bound instrument is enabled for sale 
transactions, a limit in customer user 203 's chosen (native) currency is stored in field 
120H.17. If a native cunency does not exist, the sale transaction limit of 120H.17 is 
U.S. dollars. A special value may be used to indicate that there is no sale transaction 
20 limit for the bound instrament. This special vahie may be zny vahie that is not within 
the set of acceptable values of the field. For example, if die limit of field 120H.17 is 
expressed as a positive number, die special vahie could be negative one. 

Field I20H. 18 is a flag indicating whedier die bound instrument is enabled 
for credit/return transactions. A credit/return transaction is an operation where a 
25 mercham credits, customer persona 120.1 in lieu of providing the product originally 
agreed to. 

If field 120H.18 indicates that the bound instrimient is enabled for 
credit/retom transactions, a limit in customer user 203's chosen native currency, per 
credit/remm transaction is stored m field 120H.19. If a native cunency does not exist, 
30 thecredit/remnitransactionlimitoffieldl20H.19 is U.S. dollars, A special value, may 
be used to indicate- diat there is no credit/rrtum transaction limit for the bound 
instrument, as previously described. 
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Field 120H.20 is a flag indicating whether a bound instrument is enabled 
for load operations, as previously described. 

If field 120H.20 indicates that the bound instrument is enabled for load 
operations, a limit is stored in field 120H.21. The load cash transaction limit of field 
5 120H.21 represents a limit, in native currency. If a native currency does not exist, the 
load cash transaction limit of field 120H.21 may default to U.S. dollars. A special value 
may be used to indicate that there is no load cash transaction limit for the bound 
instrument as previously described. 

Field 120H.22 is a flag indicating whether the bound instnmient is enabled 
10 for unload operations, as previously described. 

If field 120H.22 in^irat^^g that the bound instrument is enabled for unload 
cash transactions, a limit for cash transactions is stored in field 120H.23. The unload 
cash transaction limit of field 120H.23 represents a limit, in native currency. If a native 
currency does not exist, the unload cash transaction limit of field 120H.23 may 
15 preferably default to U.S. dollars. A special vahie may be used to indicate that there 
is no unload cash transaction limit for die bound instrument, as previously described. 

Field 120H.24 is a flag indicating whether the bound instrument is 
designated as the autoclose binding for customer persona 120.1. An autoclose binding 
must have its unload cash transaction flag (field 120H.22) enabled. 
20 Field 120H.2S stores a numb^ of hours over which the sales transaction 

limit stored in field 120H.17 ^lies. 

Field 120H.26 stores a number of hours over which the credit transaction 
limit stored in field L20H.19 ai^lies. 

Field 120H.27 stores a number of hours over which the load cash 
25 transaction limit stored in field 120H.21 applies. 

Field 120H.28 stores a number of hours over which the unload cash 
transaction limit stored in field 120H.23 applies. 

Field 1201 stores legal agreements as previously described. 
Whifc the foregoing description of customer persona 120.1 was set forth 
30 with respect to data relating to customer user 203, it is noted that a merchant user 303 
has merchant persona 120.2 stored in server persona data structure 120. Merchant 
persona 120.2 is shown in Figures 4E, 4F, and 4G where fields 120AA-120HH, 



120GG.1.120GG.4. and 120HH.M20HH.28 correspond to fields 120A-120H, 120G.1. 
120G.4, and 120H.1-120H.28 of Figures 4B,4C and 4D. 

2, Server Session Data Structure 130 

Server session data structure 130, shown generally in Figure 4A. stores 
5 data associated with a session. Server session data structure 130 is now described for 
customer user 203. 

Referring to Figure 4H, server session data structure 130 includes one or 
more customer session records 130. 1. Server session data structure 130 contains one 
record 130.1 for each active session of customer user 203. 
10 Server conqmter 100 identifies a session by a unique session identification 

number ("session id**). The session id is stored in field 130A. 

Messages exchanged between server computer 100 and customer computer 
200 duriz^ a session includes encrypted data. Field 130B contains an encryption key 
(known as a "session key"). The session key of field 130B is used by server cona^mter 
15 100 to calculate a key to decrypt encrypted messages received from customer computer 
200. 

Field 130C stores a session salt, preferably 8-bytes in length. As will be 
described below, messages exchanged inside a session between server computer 100, 
customer conqHiter 200 and merchant computer 300 are tiot authenticated using digital 
20 signatures. Instead, niessages exchanged inside a session are authenticated by knowledge 
of the session key and session salt described above. To ensure that die unencrypted part 
of a message is not altered, it is hashed ami the hash value is included in the encrypted 
part of the message. Use of die session salt of field 130C ensures that the hash values 
are more secure. 

25 In the present invention, customer user 203 may transact business in one 

or more currencies. Fwld 130D inclicares a denomination of currency (for example, 
U.S. dollars) that customer user 203 will use during the sessioiL 

Field 130E rqyresents a maximum amount of electronic cash (in the 
cuirency of field 130D) available to customer user 203 at the start of die session. 

30 Field 130F represents an amount of electronic cash (in the currency of 

field 13GD) available to user 203 at a particular instant during the sessioiL The initial 
vahie of field 130F is the value stored in opening amount field 130E. Thereafter, die 
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value of current amount of field 130F is determined by subtracting each amount spent 
for products during the session from the previous value of 130F. 

Field 130G indicates a date and time that the session was created. Field 
130H indicates the date and dme that the session actually closed. 
5 Field 1301 represents the maximum number of times (key use limit) that 

server computer 100 will recognize customer computer 200's use of the session key of 
field 130B. 

Field 130J represents a length of time Gcey Ufetime) that the session key 
of field 130B is valid. 

10 Field 130K stores the persona id of customer user 203. It is through the 

persona id of field 130K that a session is associated with a persona 120.1. 

Field 130L stores the status of a session associated with the session id in 
field BOA. The status is cither "open" or "closed". 

Field 130M stores an optional string (memo) provided by customer user 
15 203 describing the session associated with the session id in field 130A. Field 130M may 
contain a string provided by customer user 203 at the opening of a session and a string 
provided at the close of a session. 

Transaction data 130N comprises fields 130N.1-130N.5. Field 130N.1. 
130N.5» shown in Figure 41, are maintained for each transaction initiated by customer 
20 user 203 during the session identified by die session id m field 130A. The maximum 
number of sudi actions is equal to the key-use limit stored in field 1301. Fields 130N. 1- 
130N.5 are now described in detail with reference to Figure 41. 

Field 130N.1 contains the amount charged to customer user 203 for a 
particuiar transaction. 
25 Field 130N.2 stores the session id stored in field 130A. 

Field 130N.3 stores an order identification number ("order id") generated 
by merdiam computer 300 to identify a particular order. 

Field 130N.4 stores the session id of merchant 303 from which the 
product associated widi a particular transaction as purchased. 
30 Field 130N.S contains the index value assigned by customer computer 200 

to a particular transaction. The index value must be within die key use-limit established 
as set forth m field 1301. Because the transactions executed by customer persona 120. 1 
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may not be received by server computer 100 in the cider diat tbey are executed, die 
index value is stored in a manner, such as bit map of permitted index vahies, which 
allows server computer 100 to determine if a permitted index has been used and to take 
appropriate action should that occur. 
5 While the foregoing description of server session data structure 130, 

customer session record 130.1 was set forth witfi respect to data relating to customer 
user 203, it is noted diat a merchant 303 user has corresponding data stored in server 
session data stnicnire 130. Such a merchant session record 130.2 is shown in Figure 4J 
and 4K where fields 130AA-130NN correspond to fields 130A-130N, and fields 
10 130NN. 1-130NN.5 correspond to fields 130N. 1-130N.5. 

3- Mf^ffy Data Stmctnrt. 140 

Message log data strucoire 140 (Figure 4A) tracks messages received and 
sent by server computer 100. This permits server computer 100 to identify duplicate 
messages and respond accordingly. Duplicate messages are used to ensure consistent 
state between a client and server compuier 100 in the face of unpredictable 
communications over the Internet 50. For example, a duplicate of a valid message could 
be respoiided to witii tbc original response. Server computer 100 might not, however, 
duplicate the processing of die dopUcaie message. A record 140.1 of message log data 
structure 140 is now described with reference to Figure 4L. 

Field 140A ccmtains die persona id inchided in die message received by 
s»ver computer 100. 

Field 140B contains the session number inchided in a message CA2 
(described later) received by server computer 100. For aU otiier messages received by 
server computer 100, diis fieW is preferably nuU. 

Field 140C contains the transaction number included in a message Rl, 
BD, LUI. OSl, or CSl (described later) received by server computer 100. For any 
message CA2 received by server computer 100, this field is preferably nuU. 

Field 140D contains the index inchided in message CA2 received by 
server computer 100. For aU odier messages received by server compuier 100, this field 
is preferably null. 

FieM 140E contains a hash of, or copy of, die message received 
(incoming) by server computer 100 associated witii fields 140A-140D. Field 140F 
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contains a copy of a message sent by server computer 100 in response to the message 
saved in field 140E. 

4. Message Data Stmctnre ISO 

Message data stnicture ISO (Figure 4A) includes templates indicative of 
5 the fonnat and contents of messages used in the present invention by type and version. 
For example, a particular message may differ between one or more supported versions 
of customer application software 210 or merchant ^plication software 310. When a 
message is received by server computer 100, it is compared to a template for that 
message. As described later, if the message does not conform to the template, an error 
10 message is returned to the sender of the message. 

5. Private Key Data Stnictore MM 

Private key data stnicture 160 maintains a list of the RSA public/private 
key pairs of server computer 100 that are used in supported versions of customer 
application software 210 or merchant application software 310. As will be described 
15 later, encrypted messages sent to server conqniter 100 include a pointer which informs 
server computer 100 which RSA public key of server computer 100 was used by 
customer application software 210 or merdiant a(^lication software 310 to encrypt the 
message. In this manner, server computer 100 can find the corresponding RSA private 
key to decrypt ttae encrypted message. 

20 6. ^Wflr^ ^ f^^pu^nr^ 170 

Application dau stnicture 170 tracks existmg version(s) of customer 
plication software 210 and merchant application software 310. Application data 
structure 170 is also used to d^ennined whether an iqxiate to customer application 
software 210 or merchant application software 310 is available or necessary. For 
25 example, server computer 100 may advise a customer conqnitar 200 diat customer 
application software 210 is non-current yet usable, or that the software is no longer 
usable and nuist be r^laced. 

Figure SA dq>i^ the general structure of customer database 202. 
30 Customer dat^b^^w 202 includes customer application data structure 213, customer 
persona data structure 220, customer instrument binding data stnicture 230, customer 
session data structure 240, customer pending transaction data structure 2^, customer 
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log data structure 260, message teiiq>Iate data structure 270 aiKl customer cash data 
structure 280. Each of these data structures is now described in detail. 

1. Customer Application Data Structure 215 

Customer application data structure 215 stores data relating to server 
computer 100. Referring to Figure SB, customer application data structure 215 inchides 
record 215.1, shown there in detail. 

Field 215A contains an RSA public key for server computer 100. Tbe 
RSA public key of field 2 15 A is used by customer computer 200 to encrypt data in 
messages sent by customer computer 200 to senrer computer 100. 

Field 215B stores a uniform resource locator for ("URL") for server 
. computer 100. The URL of field 215B is die address of server computer 100 on the 
world wide web of the Internet 50. 

While the foregoing description of customer application data structure 2 15 
and record 215.1 was set forth with respect to data relating to customer user 203, it is 
noted that a merchant user 303 has corresponding data stored in merchant application 
data structure 315, shown in Figure 6B. A merchant record 315.1 is shown in Figure 
6B where fields 315A-315B corre^nd to fields 215A-215B. 

2. Costomer Persona Data Structure 220 

CustCHner persona data structure 220 stores data relating to custon^r user 
203. Referring to Figure 5C» customer persona data structure 220 includes record 
220.1, shown there in detail. 

Fields 220A-220C correspond to and contain the saitse information as 
fields 120A-120C (Figure 4B). 

FkJd 220D stores an autoclose passphrase for customer user 203. The 
autoclose passphrase is a passphrase which allows customer user 203 to close customer 
persona 120.1 in certain circumstances as described later. 

Field 220E contains a preferred language of communication for customer 

user 203. 
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A default name and address of customer user 203 is stored in field 220F. 
The default name and address of field 220F is the name and address of the individual 
whose customer persona 120. 1 is indicated by the persona id of field 220A. The default 
name and address of field 220F facilitates providing such infonnation when it is 
5 requested. 

Field 220G retains preferred customer implication software 210 settings 
(options), for example, the communication preferences (e. g. . time-out range in seconds), 
alert preferences show alerts before submitting transactions off-line and/or when logging 
on), and security preferences fe.g.> ask for pas^hrase before a payment operation)* 
10 Field220HstorestheRSAprivatekey for a customer persona 120.1. The 

RSA private key of field 220H is the complement to RSA public key of field 120C, 
stored in server database 102. 

Cash container data 2201 rqyresents fields 280A-280C shown in Figure 

5U. 

15 Instrument binding 22QJ represents fields 230A-230S shown in figure SD. 

Field 220K retains the autoclose account number associated with the 
autoclose password stored in fiekl 220D. 

Field 220L stores one or more integers representing legal agreements, in 
the pr efe r red embodiment, the operator of server conqniter 100 determines what legal 
20 agreements must be agreed to by custon^ user 203 in order for customer user 203 to 
create a persona. 

Active sessicms data 220M represents fields 240A-240K. 

Pending log data 220N represents records 2S1-2S6 of pending log data 

structure 250. 
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Transaction log data 220O represents records 261-267 of transaction log 
data structure 260. 

While the foregoing description of customer persona data structure 220 
and record 220. 1 was set forth with respect to data relating to customer user 203, it is 
noted that merchant user 303 has corresponding data stored in merchant persona data 
strucmrc 320, shown in Figure 6C. A merchant record 320.1 is shown in Figure 6C 
where fields 320A-320O correspond to fields 220A-220O. 

3. Customgr In^^tnimgnt Riniifn g Data Strocture 230 

Customer instrument binding data structure 230 retains information at 
customer computer 200 regarding bomd instruments. Referring to Figure SD, customer 
instrument binding data structure 230 includes one or more records 230.1. Cu^omer 
data base 202 contains one record 230.1 for each instrument bound to customer persona 
120.1. A detailed record 230.1 of customer instrument binding data structure 230 is 
shown in Figure SD where: 

Field 230A stores the instrument number. 

Field 230B contains a description of the bound instrumenL 

Fields 230C-230J respectively represent Ae name, address, city, country, 
postal code, country code, area code and telq>hone number of the holder of the bcMind 
instrumenL 

Field 230K stores a de£mlt currency associated with the bound instrument. 

Fields 230L-230O are flags inHicaring whether the bound instrument is 
enabled for sale transactions, credit return transactions, unload and load operations. 
Fields 230L-230O correspond to fields 120H.16, 120H,18, 120H.22 and 120H.20, 
respectively (Figure 4D). 
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Field 230P contains a status of the bound instrument. The binding status 
of field 230P corresponds to the binding status of field 120H. 15 of Figure 4D. 

Field 230Q stores a salt for the bound instrument. The salt of field 230Q 
represents a random number generated by customer application software 210. As 
5 previously described, is used by server to strengthen the result of the instrument hash 
value stored in field 120H.9. 

Field 230R stores certain information associated with a bound instrument 
and is referred to as "instrument recurring data". The recurring data is a data string 
which is used by customer application software 210 to reconstruct a set of label-value 
10 pairs identified by server conqmter 100 at the time an instrument is bound. The fields 
are returned to server computer 100 by customer computer 200 during operations that 
require use of the instrument associated with the recurring data. In this way. server 
computer 100 may receive information regarding the instrument when necessary without 
storing that information in its data strucmres. The particular label-value pairs fliat are 
15 contained within recurring data depend on die type of the bound instrument and the 
requiremcntsof die issuer of the instrument. For example, a credit card might require 
die card number, the card expiration date, and die name and address of die card holder 
to be r^umed to tiie server each time die card is used to load fiinds into person 120.1. 
The recurring data would contain data which would allow customer application software 
20 210 to rttum diis information in the proper label-vahic pair format. 

Field 230S corresponds to and stores the same information as field 120H.7 
(Figure 4D) relating to legal agreements. 

While the forgoing description of customer instrument bmding data 
strucnire 230 and record 230. 1 was set fortfi widi respect to data relating customer user 
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203. it is noted that a merchant user 303 has corresponding data stored in merchant 
persona data strucmre 330. shown in Figure 6D. A merchant record 330. 1 is shown in 
Figure 6D where fields 330A-330S correspond to fields 230A-230S. 
4. Cummer Se ssion Data Sfructnre 240 
5 Customer session data structure 240 maintains information at customer 

computer 200 relating to a session. Referring to Figure 5E. customer session data 
stnicture 240 inchides one or more records 240.1 . Customer session data strucmre 240 
contains one record 240.1 for each active session of customer user 203. A detailed 
record 240.1 of customer session data strucmre 240 is shown in Figure 5E. 
^ ° 240A-240F correspond to and contain the same information relating 

to a session as fields 130A-130F (Figure 4H). Field 240G contains die last index used 
by customer computer 200 during tbe session. Field 240H contains the same 
information as field 130M. Fields 240J-240K contain the same data as fields 130M30J. 
respectively. 

While the foregoing descrq)ti<Hi of customer session data stnicture 240 and 

record 240.1 was set forth with respect to data relating a customer user 203, it is noted 
that a merchant user 303 has corresponding data stored in merchant persona data 
strucmre 340. shown in Figure 6E. A merchant record 340.1 is shown in Figure 6E 
where fields 340A-340K correspond to fields 240A-240K (Figure 5E). 

^* Cnstmnn- Pfn#ng Tranc actimi Data Stractnre 250 

Customer pending transaction data stracdire 250 stores (1) data necessary 
to create messages sent by customer computer 200 and (2) a copy of each message sem 
by customer computer 200. Referring to Figure 5F, customer pending transaction data 
structure 250 inchules the foUowing records: pending persona registration/update persona 
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information 251, pending linlc/update financial instrument binding 252, pending cash 
payment 253, pending load/unload funds 254, pending open session record 255, and 
pending close session record 256, Each record 251-256 is now described in detail with 
reference to Figures 5G-5L. It is preferred that a pending record 251-256 be deleted 
5 upon receipt by customer computer 200 of a response message unless customer user 203 

has indicated otherwise. 

a. ffi>nHing Ppryynfl ^ly^t rationAJDdate 

Persona InfcHinatio n Record 251 
Pending persona registration/update persona information record 25 1 stores 
10 data relating to processes by which customer user 203 creates customer persona 120.1. 
Referring to Figure 5G, record 251 is shown in detail. 

Field 25 lA indicates a code which represents a type (transaction type) of 
action being performed. For example, field 251 A may contain "creation" which would 
indicate that user 203 is creating persona 120.1. If a persona 120.1 already exits and the 
15 action being performed is to change something associated widi that persona, field 251A 
may contain "modification*'. 

Field 251B stores a transaction number, that is, a unique number 
indicative of a particular action. The transaction rmmber of field 251B is generated by 
cliem application software 210. The transaction number of field 250B allows server 
20 cootqnita: 100 to send an associated reply message. Because transaction numbers are 
unique, die transaction number of field 251B also permits server computer 100 to 
ddermine whether a message Rl is a duplicate message. 

Field 251C represents the date and time that message Rl was assembled 
and sent to server cmnputer 100. 
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Field 251D stores the version of the application software 210 used to 
assemble message Rl. As further described later, the software version number of field 
251D is used to determine whether customer application software 210 is outdated. 

, Field 25 IE contains a preferred language for customer user 203, 
5 corresponding to field 220E (Figure 5B). 

Field 25 IF contains a preferred currency for customer user 203, 
corresponding to field 240D (Figure 5E). 

Field 251G stores a persona id requested by customer user 203. It should 
be noted that the requested persona id of field 251G may not be the same as the persona 
10 id of field 120A finally assigned to customer user 203, For example, server computer 
100 may reject the requested persona id of field 251G if it is already in use by anotter 
customer user 203. 

Field 251H contains the email address for customer user 203, 
correspoiKling to field 220B (Figure 5Q, 

Field 2511 contains an autoclose passphrase, corresponding to field 120F 

(Figure 4B). 

Field 251 J stores an original transaction string which is a copy of original 
message Rl sent from customer conqniter 200 to server computer lOOw 
Pmdfng T Jnlr /Update Instmnient Rec=ord 252 

Pending linkAqxlate record 252 stores data relating to processes by which 
customer user 203 binds an instrument to customer persona 120.1 or iqxlates an existing 
bound mstrumrat. Referring to Figure 5H, a record 252 is shown in detail. 

Field 252A indicates a code which represents a type of action (transaction 
type) being performed. For exanq)le. field 252A may contain "link" which would 
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indicate that user 203 is linking an instnunent to customer persona 120.1. If the action 
being performed is to change something associated with an instrument already linked 
with that persona, field 252 A may contain 'update*. 

Fields 2S2B-2S2D correspond to and store the same information as field 
5 25 lB-25 ID of Figure 5G. These fields relate to the transaction number, transaction date 
and time, and software version, respectively. 

Field 252E contains the persona id of customer user 203, corresponding 
to field 220A (Figure 5B). 

Field 252F stores die number of the instrument being bound to persona 

10 120.L 

Field 252G stores additional customer identification information needed 
to use the instrument being bound, for example, American Express card customer 
identification mmiber. 

Field 252H stores the name of tbs person to ^^m die instrument being 
15 bound was issued. 

Field 2S2I stores die expiration date of the instrument being bound. 

Fields 252J-252Q respectively store the street address, city, state, postal 
code, country, country code, area code and telephone number of the person to whom the 
instrument being bound was issued. 
20 Fieki 2S2R contains customer user 203's selected description of die 

instrument being bound. 

Instrument recurring data field 252S stores information stored in field 
230R as relates to bound instruments. 

Field 252T stores die type of instrument being bound, for example, VISA, 
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American &q)Tess, etc. 

Field 2S2U contains a random number salt, generated by customer 
computer 200. The salt of field 2S2U is used to strengthen the instrument number hash 
maintained at server 100. 
5 Field 252V stores a flag which if set indicates that the instrument is the 

autociose account instnunent. 

Field 252W stores an original transaction string which is a copy of the 
original message BIl sent by customer conqniter 200 to server computer 100. 
c. Pending Cash Payment Record 253 

10 Pending cash payment record 2S3 stores data relating to tiansactioDs 

involving cash payments. Referring to Figure SI, a record 253 is shown in detail. 

Field 253 A indicates a code which represents a type of action (transaction 
type) being performed. For example, if a session is open, then field 2S4A may indicate 
"cash payment** indicating that customer user 203 is sending a message CAl (described 
15 later). 

Fields 253B-253D correspond to and store the same information as fields 
251B-251D (Figure 5G). These fields relate to the transaction number, transaction date 
and time, and software version, respectively. 

Field 2S3E contains tte persona id of customer user 203, corresponding 
20 to field 220A (Hguxe 5Q. 

Field 2S3F stores an order identification number ("order id"). The order 
id of field 253F is generated by merchant computer 3(X) to identify a particular order. 

Field 253G contains merchant user 3Q3*s persona id 120AA (Figure 4E). 

Held 253H stores an amount of electronic cash that a customer user 203 
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is paying for a product which is the subject of the current transaction. 

Field 2531 provides a location for an optional customer user 203 generated 
memo that describes this particular transaction. 

Field 253J contains the URL of a merchant computer 300 to which 
5 customer user 203 wishes to direct a cash payment. Customer application software 210 
uses the URL field 253J to direct pay cash requests in the form of message CAl to 
merchant computer 300 for forwarding to server computer 100. 

Field 253K stores the session-id of the session during which the current 
transaction was initiated. 
10 Field 253L stores the index associated with current transaction. 

Field 2S3M stores an original transaction string which is a copy of 
message CAl sent by customer computer 200, through merchant conqniter 300, to server 
computer 100. 

Field 253N contains the URL of merchant computer 300 on which 
15 customer user 203 wishes to cancel a transaction. Customer application software 210 
uses the URL field 253N to cancel transaction requests in the form of message CAl. 

Field 2530 contains tte URL of merchanf conqmter 300 to indicate a 
successftil cancellation of a transaction by customer 203 . Customer application software 
2 1 0 uses the URL field 2530 to indicate a successftil cancellation in the form of message 
20 CA4. 

Field 253P stores the URL of merchant conqnaer 300 to indicate a fiulurc 
of a transaction. Customer application software 210 uses tte URL field 253P to indicate 
a failure of a transaction in form of message CA4. 

d. IVndinP I^/Unload FmA s Record 254 
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Pending load/unload funds record 254 stores data relating to transactions 
involving loading and unloading of electronic cash. Referring to Figure 5J, a record 254 
is shown in detail. 

Field 254A indicates a code which represents a type of action (transaction 
5 type) being performed. For example, field 254A may contain "load" which would 
indicate that user customer 203 is "transferring" funds into the cash container field 280B 
of record 280.1 from the instrument identified in field 254F. Alternatively field 254A 
may contain "unload" which would indicate that customer user 203 is "transferring" 
electronic cash funds from cash container field 280B to the instrument identified in field 
10 254F. 

Fields 254B-254D correspond to and store the same information as fields 
251B-251D (Figure 5G). These fields relate to the transaction number, transaction date 
and time, and software version, respectively. 

Field 254E contains die persona id of customer user 203, corresponding 
15 to field 220A (Figure 5Q. 

Field 254F stores an account number identifying a bound instrumeru from 
which fuiKis are to be loaded or to which funds are to be unloaded. 

Field 254G stores an amount of funds to be loaded from or unloaded to 
a bound instrament 

20 Field 254H stores die type of account from which funds are being load 

or u> which funds are being loaded. 

Field 2541 stores an original transaction string which is a copy of message 
LUl sent by customer computer 200 to server computer 100. 
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Pending session record 255 stores data relating to processes by which 
customer user 203 creates a session. Referring to Figure 5K, a record 255 is shown in 
detail. 

Field 255A indicates a code which represents a type of action (transaction 
type) being performed. For example, field 255A may contain "opea-session" which 
would indicate that user customer 203 is creating a session. 

Fields 2S5B-255D correspond to and store the same information as fields 
251B-2S1D (Figure 5G). These fields relate to the transaction mmiber, transaction date 
and time, and software version, respectively. 

Field 255E contains the persona id of customer user 203, corresponding 
to field 220A (Figure 5C). 

Field 25SF stores an amount of electronic cash to be made available 
during a session. 

Field 2SSG stores a vahie representing die maximum mmiber of 
transactions (key use limit) that customer user 203 may request during a session. 

Field 2S5H stores a vahie representing the maximum amount of time (key 
lifetime) the session wiU remain open. 

Field 2S5I stores the text of an optional description of a session as entered 
by customer user 203. 

FieU 2S5 J stores die currency associated with die amount value stored in 

field 255F. 

Field 255K stores an original transaction string which is a copy of 
message OSl sent by custoo^ conqniter 200 to server computer 1(X). 
f. Session Record 256 



34 



Pending close session record 256 stores data relating to processes by 
which customer user 203 closes a session. Referring to Figure 5L, a record 256 is 
shown in detail. 

Field 256A indicates a code which represents a type of action being 
performed. For example, field 256A may contain "close-session" which would indicate 
that user customer 203 is closing a session. 

Fields 256B-256D correspond to and store the same information as fields 
251B-251D (Figure 5G). These fields relate to the transaction number, transaction date 
and time, and software version, respectively. 

Field 256E contains the persona id of customer user 203, corresponding 
to field 220A (Figure 5Q. 

Field 256F contains either "yes" or "no". The vahie of field 256F 
determines whedier customer user 203 has elected to receive a log of the transactions 
initiated by customer user 203 during the session to be closed. 

Field 256G stores the session-id of the open session to be closed. 
Alternatively, if all open sessions arc to be closed, field 256G will be null. 

Field 2S6H stores the text of an optional description related to the session 
closing as entered by customer user 203. 

Field 2561 stores an original transaction string which is a copy of message 
CSl sent by customer conqniter 200 to server conqaiter 100. 

6. Customer Log Data Strnctiire 2^ 

Referring to Figure S A, customer log data structure 260 matntain<f a copy 
of each message received by customer computer 200. Customer log data strucuire 260 
stores data received by custwner cranputcr 200 from server computer 100, Referring 
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to Figure SM, customer log data structure 260 includes the following records: persona 
registration/update persona infonnation response 261, link/iqxlate financial instalment 
binding response 262, cash payment response 263, load/unload funds response 264, open 
session response 265, payment request 266, and close session response 267. Each 
5 record 261-267 is now described in detail with reference to Figures 5N-5U. 
a« Persona Registration/Update Response 

Persona Information Record 261 
Persona registration/update persona ijofonnation record 261 stores data 
relating to the response of server computer 100 to a request to create a customer persona 
10 120.1 by customer user 203. Referring to Figure 5N, a record 261 is shown in detail. 

Field 261A indicates a type of action that was requested and is the same 
as the value of field 231 A of record 251. Field 261B stores a transaction number that 
is the same as the value stored in 2S1B. 

Field 261C represents the date and time that message Rl was assembled 
15 and sent to server computer 100. 

As will be discussed later, messages from customer computer 200 to 
server conqniter 100 convey a code containing the version number of the customer 
i^lication software 210 used to create the message. At server ccmqmter 100, each 
software versicm is associated with one of three "status" labels: current, warning, or 
2 0 fatal. Server con^Hiter 100 checks the software version reported in custon^'s messages 
and includes in its reply message one of the three possible status labels. The status label 
returned in message R2 is stored in software severity field 261D. A text message 
regarding the content of software severity field 261D may also be returned by server 
computer 100 and, if so, is stored in field 261E. 
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A code representing the success or faUure of message Rl is returned by 
server computer 100 and is stored in response code field 261F. A text message 
regarding the content of the response code field 261F, if sent by server computer 100, 
is stored in field 261G. 

Field 261H stores a persona id requested by customer user 203. As 
described below, if the requested persona id is in use, server conq)uter 100 will suggest 
a persona id to customer user 203. The persona id suggested by server computer 100 
is stored in field 2611. 

Field 26II contains the email address for customer user 203 corresponding 
to field 220B (Figure 5C)- 

Field 26iK contains a preferred language for customer user 203, 
corresponding to field 220E (Figure 5C). 

Field 261L contains a preferred currency for customer user 203, 
corresponding to field 240D (Figure 5E). 

b. LinkAJpda te Response Tngfmmon t Record 262 

Unlc/update instrument record 262 stores data relatii^ to the response by 
server computer 100 to a reqi^ by customer user 203 to bind an instrtraient to 
customer persona 120. 1. Referring to Figure 50, a record 262 is shown in detail. 

Field 262A indicates a type of action (transaction) that was requested and 
is the same as the vahie of field 252A of recoid 252. 

Fields 262B-262G correspond to aixl store the same information as field 
261B-261G of Figure 5N. These fields relate to the transaction date and time, software 
severity code, software message, response code, and response message respectively. 

Field 262H contains the persona id of customer user 203, corresponding 
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to field 220A (Figure 5Q. 

Field 2621 stores the number of the instrument being bound to customer 
persona 120.1. Field 262J stores the type of instnmient being bouiKi, for example. 
VISA, American Express, etc. to customer persona 120. L 

Field 262K stores customer identification information needed to use the 
instrument being bounds for example, American Express card customer identification 
number. 

Field 262L stores the name of the person (customer) to whom the 
instrument being bound was issued. 

Field 262M stores the expiration date of the instrument being bound. 

Fields 262N-262U respectively store the street address, city, state, postal 
code, country, coimtry code, area code and telephone number of the person to whom the 
instrument being bound was issued. 

Field 262V stores the text of a description of the instrimient being bCHmd 
as entered by customer user 203. 

Field 262W stores the native currency, if ai^ associated with an 
instrumetit which is returned by server computer 100. 

Field 262X stores the name of the issuer of the instrument which is 
returned by server computer 100. 

Field 262Y stores the country of issuance of the instrxmient. 

Field 262Z stores a flag which if set indicates that the instrument is the 
autoclose account instnmient. 

c. Cagli PaY)ment R^spopse Record 263 

Cash payment response record 263 stores data relating transactions 
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involving cash payments and sessions. Referring to Figure 5P, a record 263 is shown 
in detail. 

Field 263A indicates a type of action (transaction type) that was requested 
and is the same as the value of field 253 A of record 253. 

Fields 263B-263E correspond to and store the same information as field 
261B-261C and 261F-261G of Figure 5N. These fields relate to the transaction number, 
date and time, response code, and response message respectively. 

Field 263F contains the persona id of customer user 203, corre^ndii^ 
to field 220A (Figure 5C). Field 263G stores an order identification number ("order 
id"). The order id of field 2631 is generated by merchant computer 300 to identify a 
particular order. 

Field 263H contains a merchant user 303 persona id 120AA. 

Field 2631 provides a location to store a message fix)m merchant user 303. 

Field 263J stores an amount of electronic cash diat a customer user 203 
is paying for a product which is the subject of the current transaction. 

Field 263K provides a location for an (^tional customer user 203 
generated memo. 

Field 263L stores the session-id of the session during v^ch the current 
transaction was initiated. 

Field 263M stores the index associated with the current transaction. 

d. Load/Unload Funds Rgg xHise Record 264 

LoadAmload funds response record 264 stores data relating to the response 
of server computer 100 to a request to load or unload funds by customer user 203. 
Referring to 



Figure SQ, a record 264 is shown in detail. 

Field 264A iiKlicates a type of action (transaction type) that was requested 
and is the same as the value of field 254A of record 254. 

Fields 264B-264G correspond to and store the same information as field 
5 261B-261G of Figure 5N. These fields relate to the transaction number, date and time, 
software severity code, software message, response code, and response message 
respectively. 

Field 264H contains the persona id of customer user 203, corresponding 
to field 220A (Figure 5C). 
10 Field 2641 stores an account number identifying a boimd instrument from 

which electronic cash is to be loaded or to which electronic cash is to be unloaded. 

Field 264J stores an amount of electronic cash to be loatted from or 
unloaded to a bound instrument. 

Field 264K stores an amount of any fee charged by the operation of server 
15 computer 100 to load or unload funds from customer persona 120.1. 

Field 264L stores an amount equal to the available balance of the funds 
held by customer persona 120. 1 as d^ermined by server computer 100, corresponding 
to the vahie stored in fkld 120G.2 (Figure 4Q. 

Field 264M stores an amount of fimds which have been loaded (or 
20 unloaded) but are not available to customer user 203. These funds are awaiting 
processing, corresponding to the vahie stored in field 120G.3 (Figure 4Q. 

e. Open SsSSSm Response Record 265 

Create session response record 265 stores data relating to the response of 
seirver computer 100 to a request to create a session by customer user 203. Referring 
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to Figure 5R, a record 265 is shown in detail. 

Field 265A indicates a type of action (transaction type) that was requested 
and is the same as the value of field 255 A of record 255. 

Fields 265B-265G correspoixi to and store the same information as field 
261B-261G of Figure 5N. These fields relate to the transaction number, date and time, 
software severity code, software message, response code, and response message 
respectively. 

Field 265H contains the persona id of customer user 203, corresponding 
to field 220A of Figure 5C. 

Field 2651 stores an amount of electronic cash made available during a 

session. 

Field 265J stores a value representing the maximum number of 
transactions (key use lunit) that customer user 203 may request during a session. 

Field 265K stores a value representing the mflTimnm amount of time (key 
lifetime) die session will remain open. 

Field 265L stores a session id number. 

Field 265M stores the text of an optional description of the session to be 
opened as entered by customer user 203. 

Field 265N stores an amount of any fee charged by die operation of server 
conq)uter 100 to create a session. 

Field 2650 stores tte available balance remaining in the cash container 
(field 120G.2) after the vahie in amount field 2651 is subtracted. 

r. Payment RcQuest Record 2M 

Payment request record 266 stores data relating to a request fit>m 
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merchant user 303 for payment for the product. The request is in the fonn of a message 
PRl (described later) which is sent by merchant computer 300 to customer computer 
200, Referring to Figure 5S, a record 266 is shown in detail. 

Field 266A contains a merchant user 303 persona id 120AA. 

Field 266B stores an order identification number ("order id"). The order 
id of field 266B is generated by merchant computer 300 to identify a particular order. 

Field 266C stores an amount of electronic funds that a customer user 203 
is paying for the product which is the subject of the current transaction. 

Field 266D stores a list of credit cards accepted by merchant 203 for 

payment. 

Field 266E provides a location to store a message (note) from merchant 

user 303. 

Field 266F stores die pay-to-URL. The value of label-value pair 50131 
is an Internet SO uniform resource locator. The Internet SO uniform resource locator of 
label-value pair S013I is the address on the Internet SO to which customer conqwter 200 
is to sends message CAl, described later. 

Qose session response record 267 stores data relating to die response of 
server conqmter 100 to a request to close a session by customer user 203. Refer ring to 
Figure 5T« a record 267 is shown in detail. 

Field 267A indicates a type of action (transaction type) that was requested 
and is the same as the vahie of field 2S6A of record 256. 

Fields 267B-267G correspond to and store the same information as field 
261B-261G of Figure 5N. These fields relate to the transaction number, date and time. 
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software severity code, software message, response code, and response message 
respectively. 

Field 267H contains the persona id of customer user 203. corresponding 
to field 220A (Figure 5Q. 

Field 2671 stores an amount of electronic cash remaining in the session 
after the close of a session after all payments and fees have been deducted. 

Field 267J stores the transaction log returned by server computer 100 if 
requested by customer user 203 in message CSl. This would also indicate whether or 
not a transaction log was returned. 

Field 267K stores an amount of any fee charged by the operation of server 
computer 100 to close the session. 

7« Messay Tg nplatP riat a Structure 270 
Referring to Figure 5A, message template data structure 270 tracks the 
format and contents of messages that customer user 203 sends and receives. A message 
which contains all the required labels with valid values fe.^. . syntax, etc.) as determined 
by reference to message template data structure 270 will be processed even if there are 
extraneous label-value pairs. A message which does not contain all the required label- 
value pairs, or which inchides labels associated with invalid values as determined by 
reference to message template data structure 270 will fail as to form. 

While tbc foregoing description of message templates 270 was set fordi 
widi respect to data relating a customer user 203, it is noted that a merchant user 303 
has corresponding data stored in message templates 380, shown in Figure 6A. 
S. CMh rnnfajlty r Data Strnrtiire 2X0 

Customer cash container data structure 280 maintain s information at 



customer computer 200 relating to cash containers. Referring to Figure 5U, cash 
container data structure 280 includes one record 280.1 for each cash container 
established by customer user 203. A detailed record 280. 1 of customer cash container 
data structure 280 is shown in Figure SU. 
5 Fields 280A*280C correspond to and contain the same information relating 

to a cash container as fields 120G.M20G.3 (Figure 4Q. 

While the foregoing description of customer cash container data structure 
280 and record 280.1 was set forth with respect to data relating a customer user 203, 
it is noted that a merchant user 303 has corresponding data stored in merchant cash 
10 container data structure 345, shown m Figure 6F. A mercham record 34S. 1 is shown 
in Figure 6F where fields 345A-345C correspond to fields 280A-280C (Figure 5U). 

C. Mp^hflfi^ Datab^ 305 

The database 302 of merchant computer 300 is described next. 
Figure 6A depicts the general structure of the merchant database 302 of 
15 mercham conqyuter 300. Figure 6 A, depicts merchant application data strucmre 315 
(previously described), merchant persona data structure 320 (previously described), 
merchant instrument binding data structure 330 (previously described), merchant session 
data structure 340 (previously described), merchant amount data structure 350, merchant 
sales session data structure 360, merchant cash log 370, message template data structure 
20 380 (previously described), and merchant cash container data structure 345 (previously 
described). Data structures 350, 360 and 370 are now described. 

1. Merchant Amount Data Structure 350 
Merchant amount data structure 350 tracks the amount of electronic cash 
mercham user 303 e^qpects to receive from customer user 203 for an order. Referring 
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to Figure 7A, record 350 is shown in detail. 

Field 350A stores an order id, corresponding to field 253F of Figure 51. 

Field 350B stores an amount of electronic cash (amount of transaction) 
corresponding to field 253H of Figure 51, 

Field 350C is a flag indicating whether an order has been paid for by 
customer user 203. 

2. Merchant Sales Session Da ta Stmcture 360 

Merchant sales session data structure 360 tracks the sessions of merchant 
user 303. Referring to Figure 7B, record 360 is shown in detail. 

Fields 360A-360H correspond to fields 340A-340H (Figure 6E), Fields 
360J-360K correspond to fields 340I-340K (Figure 6E). Field 360G stores the date that 
the merchant sales session identified by session id field 360A was opened. Field 360H 
stores the date that such session was closed. Field 3601 stores tte status of the session 
associated with the session id in field 360A. The status is eidier "open" or ''closed." 
Field 360L stores persona id of merchant user 303. 

3. Merchant Cash Log Data Structnre 370 

Merchant cash log 370 tracks electronic cash transactions and session data 
not retained m merchant sales session data structure 360. More specifically, merchant 
cash log data structure 370 stores data relating to collections and sessicHis tnitiatf^ by a 
merchant user 303. Referring to Figure 7C, a record 370 is shown in detail. 

Fields 370A-370M store data relating to collection messages CA2 
submitted by merchant computer 300 to server computer 100. Those fields are now 
described in detail. 

Field 370A indicates a type of action being performed. In this case, the 
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type stored in field 370A is "collection". 

Field 370B stores a status of the current collection request. The status of 
field 370B may irchide "attempt", "success" or "failure". The label "attempt" will be 
returned when the request has been sent to server computer 100 but no response has 
5 been received. If the request is processed by server computer 100 and the collection 
request is honored, field 370B will contain the label "success". If server computer 100 
denies the request, field 370B will contain the label "failure" and field 370M will include 
a code identifying the reason for such failure. 

Field 370C stores an order identification number ("order id"). The order 

10 id of field 370A is generated by merchant computer 300 to identify a particular order. 

Field 370D stores the session id of field 240A used by customer computer 
200 in the current collection request. Field 370E stores die index of field 240G 
used by customer computer 200 in the current collection request. 

Field 370F stores the currency of field 240D used by customer computer 
15 200 in the current collection request. 

Field 370G stores die session id of field 340 A used by merchant computer 
300 in the current collection request. 

Field 370H stores the index of label-value pair 5213D used by merchant 
computer 300 in the current collection request. 
20 Field 3701 stores the currency of field 340D used by merchant computer 

300 in the current collection request. 

Field 37QJ stores an amount of electronic cash funds requested to be paid 
to merchant user 303 in the current collection request. 

Field 370K stores an amount of electronic cash credited to mer c h a nt cash 
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container field 345B for the current collection. The amount of electronic cash credited 
is null if the status of field 370B is null. 

Field 370L stores an amount of electronic cash fiinds paid to the operator 
of server computer 100 for processing the current collection request (i.e., a fee). 

If the content of status field 370B is "failure", field 370M stores a result 
code. The result code is used by n^hant appUcation software 310 to associate a 
message with the faihirc reported in stetus field 370B. Thus, the code returned in field 
370M could prompt merchant sqyplication software to display a message such as 
'collection failed due to inadequate funds.* 

Fields 370N-370T store data relating to sessions initiated by merchant 
con^)uter 300 (message OSl). Those fields are now described in detail. 

Field 370N indicates a type of action being performed. In this case, the 
stored in field 370N is "OS", 

Field 370O stores a status of the current collection request. The stams 
of field 370O may include "attempt", "success" or "failure". The label "attenqrt" will 
be returned when the request has been sent to server computer 100 but no response has 
been received. If the request is processed by server conqniter 100 and the collection 
request is honored, field 370O wiU contain die label "success". If server computer 100 
denies die request, field 370O wiU contain the label "failure" and field 370T will include 
a code identifying the reason for such £ulure. 

Field 370P stores a transacticm number, that is, a unique number 
indicative of a particular session initiated by merchant conqniter 300, 

Field 370Q stores a merchant user 303's requested amount of time that 
dwj current session should last (i.e., requested session duration). 
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Field 370R stores a merchant user 303 's requested number of times that 
the session key of field 340J can be used (i.e., requested session count). 

If the status of field 370O is *success\ field 370S stores a session id for 
merchant computer 300 for the current session. 
5 If the content of status field 370O is "failure", field 370T stores a result 

code. The result code is used by merchant application software 310 to associate a 
message with the failure reported in status field 370T. 

nL Gmeral Information 

The preferred format of messages used in the present invention is now 

10 described. 

Due to the nature of the Internet SO, the present invention uses a message 
transmission independent mechanism so that messages can be transmitted using several 
different protocols. These protocols may include e-mail (simple mail transport protocol) 
aiKi world wide web (hypertext transport protocol or other protocols, such as remote 
15 procedure protocol (RPQ). Therefore, messages used in the present invention have a 
particular and preferred format that is not specific to the transport protocol. The 
particular and preferred format is based on RFC 822, which is well known in the art and 
therefore, only briefly described. 

Figure 7Ddq>icts the format of a sample message 4000. Saaq>le message 
2 0 4000 iiKhides header 4005, body 4010 and trailer 40S0. Body 4010 includes transparent 
(unencrypted) label-vahie pairs 4013A, 4013B, etc. and may include opaque (encrypted) 
label vataie pair 4017. (Label-vahie pairs consist of a label and data relating to the label, 
separated by a label terminator, for example, "name: Brian*.) 

Header 400S defines the start of sample message 4000. Header 4005 may 
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inchide a system identifier, for example, "CyberCash" (the assignee of the present 
invention) and a number of the message protocol ("protocol number") in which sample 
message 4000 was assembled. 

Transparent label-value pain 4013A, 4013B, etc. inchidc any clear (non- 
5 encrypted) text associated with sample message 4000. Encryption and decryption are 
described below. 

^ Opaque label-value pair 4017 includes the label "opaque". The value of 

opaque label-value pair 4017 is a block of encrypted data. The vahie of <H)aque label- 
value pair 4017 inchides a predetermined set of label-value pairs encrypted with a DES 
10 key. After encryption, the vahie is preferably base-64 encoded. The predetermined stt 
of label-value pairs is referred to herein as the "opaque section contents" of sample 
message 4000, For request messages sent outside of a session (Rl, BIl, LUl and CSl), 
the value of opaque kibel-value pair 4017 begins with that DES key. RSA encrypted 
under a public RSA key of server computer 100, RSA encryption is computationally 
15 ejqjensive. For reply messages (R2, BI4, LU2, 0S2 and CS2) and messages inside a 
session (CAl. CA2, CA3 and CA4), no additional information, beyond the opaque 
section contents, is required in the value of opaque label- vahie pair 4017, thus avoiding 
the expense of RSA encryptioxL The opaque section contents varies in length and 
represents data encrypted with the DES key used. 
20 Trailer 4050 closes sanq)le message 4000. Trailer 4050 preferably 

inchides a transmission checksum. It is preferred that the transmission checksum of field 
4050D be an MD5 hash performed on all printable characters in header 4005 and those 
^ypearing in body 4010. Thus, all white space, including new-lines, spaces, tabs, 
carriage returns, etc. are omitted bom the gherirciim hash. In this manner, the 
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correctness of the message transmission can be checked while avoiding sensitivity to 
gateways or processing that might, for example, change the line terminator sequence or 
convert tabs to spaces. 

Encryption and decryption techniques used in the present invention are 
5 now described. 

The present invention preferably uses both RSA and DBS methods for 
data encryption and decryption. Such methods axe well known in the art. RSAisfiiUy 
described in United States Patent No. 4,405,829, The present invention preferably relies 
on 768-bit RSA keys reflecting a balance between concerns relating to security, 
10 execution time, and export control. The size of the RSA key may change as high-end 
conqmters with fast processing speeds become more prevalent in customer installations 
and the export requirements are relaxed. As is known to those skilled in the art, other 
public/private asymmetric key systems (such as Rabin, and EIGamal) could be used in 
the current invention for authentication purposes. 
15 In the present invention, digital signatures are used to authenticate 

information. The details of digital signatures are widely discussed in computer security 
literature. The present invention utilizes two methods for authentication: RSA/MDS 
digital signatures ajod knowledge of shared information fe.^. . a salt value and/or a key 
value). 

20 As mentioned above, the present invention also dqpends on hashing of 

data. A hash preferably is calculated using the well-known MDS algorithm which is 
described in Internet publication RFC 1321, applied to a "synthetic message". 

If a label-value pair is specified in a hash input, but is not present in a 
notessage, the label and label terminator are preferably omitted from the hash. 
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IV. Processps of the Present InTention 

A. Download And InstaUation Process 400 

During die download and installation process 400 as previously described 
with respect to Figure 3A, an RSA public key of server computer 100 is stored in field 
5 215A of customer appUcation data structure 215. Merchant computer 300 obtains a copy 
of user application software 153 in the same manner as customer user 203 using 
download and installation process 400. In such case, user application software 153 
resides on merchant computer 300 as a component of merchant application software 310 
and an RSA public key of server computer 100 is stored in field 315A of merchant 
10 qiplication data structure 315. 

B. Registration Process 401 

Figure 8 depicts a flow diagram ilhistrating registration process 401 which 
begins at step 1201. 

At step 1202, customer ^jplication software 210 prompts or lequests 
customer user 203 to enter information relating to customer user 203. This information 
will be inchided in message Rl sent to server computer 100 and will become part of 
customer persona 120.1. In the preferred embodiment, customer user 203 enters a 
preferred language of communication, a currency in which transactions wiU be 
processed, a requested persona id, an email address and an autoclose passphiase. 

At step 1202A, customer i^iplication software 210 generates an RSA 
public/privaie key pair for customer computer 200. Hie RSA public key is stored in 
field 220C of customer persona data structure 220 (Figure 50. The RSA private key 
is stored in field 220H of customer persona data structure 220 (Figure SQ. 

At step 1203, message Rl is assembled m accordance with message 
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assembly procedure 800, depicted in Figure 9. Message Rl will be sent from customer 
computer 200 to server computer 100 and will include the information entered by 
customer user 203 at step 1202. Message assembly procedure 800 is now described with 
reference to Figure 9. 

5 Message assembly procedure 800 begins a step 801. Steps 802A-802B 

create transparent label-value pairs 4213A-4213D of message Rl, shown in Figure lOA. 
Steps 802C-813 create opaque label-value pair 4217 of message Rl, based upon the 
opaque section contents of message Rl, shown in Figure lOB. Steps 814-817 assemble 
header 4205. transparent label-value pairs 4213A-4213D. opaque label-value pair 4217 

10 and trailer 4250 of message Rl. 

At step 802A, customer application software 210 accesses message 
tenq)late data structure 270 (Figure 5A) to obtain a list of labels, which, when matched 
iq> with associated values, make up transparent label-value pairs 4213A-4213C of 
message Rl. At step 802B, values are associated with each label as follows: 

15 Label-vahie pair 4213A has the label "transaction". The vahie of field 

4213A is a transaction number, generated by client software 210, which uniquely 
identifies message Rl . The vahic of label-value pair 4213 A allows server computer 100, 
iqx>n receipt of message Rl, (1) to send an associated reply message R2, described later, 
and (2) to d^eimine if message Rl is a duplicate message (L&., already received by 

20 server conqniter 100). The vahie associated with label-value pair 4213A is stored in 
field 251B of pending persona registration/update persona information record 251 
(Figure 5G). 

Label-value pair 4213B has the label "date" . The vahie of label-value pair 
4213B indicates the date and time that message Rl was assembled and sent to server 



computer 100, according to the clock of customer computer 200. The value associated 

with label-value pair 4213B is stored in field 251C. 

Label-value pair 4213C has the label "serverkey". As described below, 

a DES key/IV pair used by customer computer 200 to encrypt the opaque label-value 

pair 4217 of message Rl is encrypted using an RSA public key of server computer 100. 

The vahxe of label-value pair 4213C points to the corresponding RSA private key stored 

in server private key data structure 160 (Figure 4A). 

Label-value pair 4213D has the label "service-category". The value of 

label-value pair 4213D is a label which may be used to route message Rl to a processor 

within server computer 100 that handles messages of a particular service category. This 
option permits the functions of server computer 100 to be distributed among multqile 
processors thereby improving capacity of the system. 

At step 802C, customer application software 210 uses well known 
techniques to generate a random 128-bit quantity. It is preferred fliat the first 64-bits of 
die quantity so generated be treated as a 56-bit DES key and the second 64-bits be 
treated as a 64-bit initialization vector ("IV"), The 56-bit DES key is represented as a 
64-bit quantity having tbt least significant bit of each ei^t bit byte ignored. This 128- 
bit quantity may be viewed as a DES key/IV pair. The DES key/IV pair is stored in a 
temporary register. 

Next, at step 804, customer application software 210 retrieves the RSA 
public key for server computer 100 from field 215A of client application data strucmre 
215 (Figure 5B). As stated previously, the RSA public tey for server computer 100 is 
preferably 768-bits in length. Of course, other length RSA keys may be used. At step 
806, Ae RSA public key retrfeved at step 804 is used to encrypt the DES key/IV pair 

53 



created at step 802. 

At step 807, customer application software 210 accesses message template 
data structure 270 (Figure 2B) to obtain a list of labels, which, when matched up with 
associated values, make up the opaque section contents of message Rl . shown in Figure 
5 lOB. At step 808, vahies are associated with each label as foUows: 

Label-value pair 4217A has the label "type". The value of label-value 
pair 42 17 A references a record in message data structure 270 (Figure 2B) which sets 
forth the labels of message Rl. The value of label-value pair 4217A is obtaii^ from 
customer application software 210 which generates the label when customer user 203 
10 initiates the registration process. 

Label-vahie pair 4217B has the label "server-date". The value of label- 
vahie pair 4217B indicates the date and time message Rl was assembled as measured by 
customer computer 2(X)'s perception of die date of server computer l(X)'s clock. 

Label-value pair 42 17C has the label "swversion* (software version). The 
15 value of label-value pair 4217C indicates the version of customer application software 
210 communicating with server conqniter 1(X). The value of label-value pair 4217C is 
obtained from data embedded in customer application software 210. The value 
associated widi label-vahie pair 4217C is stored in field 25 ID. 

Label-vahie pair 4217D has the label 'content-language". The value of 
20 label-vahie pair 4217D indicates a preferred language of communication for customer 
user 203. The vahie of label-vahie pair 4217D is obtained from customer user 203 
during registration process 401 at step 1202. The vahie associated with label-vahie pair 
4217D is stored in field 2S1E. 

Label-value pair 4217E has the label "default-currency". The value of 
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label-value pair 4217E indicates a default cunency in which transactions of customer 
user 203 wUl be processed, unless changed by customer user 203. The value of label- 
value pair 4217E is obtained from customer user 203 during registration process 401 at 
step 1202 of Figure 8. The value associated with label-value pair 4217E is stored in field 
S 251F. 

Label-value pair 4217F has the label "requested-id". The value of label- 
value pair 4217F indicates the persona id requested by customer user 203. The vahie 

of label-vahie pair 4217E is obtained from customer user 203 during registration process 
401 at step 1202 of Figure 8. The value associated with label-vahie pair 4217F is stored 
10 in field 251G. 

Label-vahic pair 4217G has the label "email". The value of label-vahie 
pair 4217G indicates an email address for custraner user 203. The vahie of label-vahie 
pair 4217G is obtained from customer user 203 during registration process 401 at step 
1202 of Figure 8. The vahie associated with label-vahie pair 4217G is stored in field 
15 251H. 

Label-vahie pair 4217H has the label "agreements". The vahie of label- 
vahie pair 4217H indicates legal agreements which customer user 203 has accepted in 
order to use the present invention. Legal agreements arc presented to customer user 203 
at step 1202 of Figure 8. The value of label-vahie pair 4217H is generated when an 
20 agreement is accepted by customer user 203 and stored m field 220L of customer 
instrumoit persona data strucoire 220 (Figure 5Q. 

Label-value pair 42171 has the label "autoclosc-passphrase". The vahie 
of label-vahie pair 42171 faidicates an autoclose pasq>hrase for customer user 203. The 
vahie of label-vahie pair 42171 is provided by customer user 203 during registration 
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process 401 at step 1202 of Figure 8. The value associated with label-value pair 42171 
is stored in field 220D of customer persona data structure 220 and field 25 II of customer 
pending data structure 250. 

Label-value pair 4217J has the label "pubkey". The value of label-value 
5 pair 4217J represents the RSA public key for customer persona 120.1 generated by 
customer application software 210 during registration process 401 at step 1202A of 
Figure 8. 

Referring again to Figure 9, at step 810, the digital signature for message 
Rl, represented by label-value pair 4217K of Figure lOB, is created. Label-value pair 

10 4217K has the label "signature". The value of label-value pair 4217K represents the 
digital signature of customer persona 120.1. For message Rl, the value of label-value 
pair 4217K is a hash of the printable U.S. ASCII characters in the label-value pairs 
4213A-4213C. and label-value pairs 4217A-4217J in alphabetical order, encrypted with 
the RSA private key of customer persona 120.1. The RSA private tey of customer 

15 persona 120, 1 is obtained from field 220H (Figure SC.) 

At step 812A, label-value pair 4217K, created in step 810 is appended to 
label-vahie pairs 4217A-4217J. Label-value pairs 4217A^217K are encrypted widi DBS 
key/IV pair stored in the temporary register at step 802C. At step 812B, the result of 
step 812A is appeiKled to the RSA-encrypted DBS key/IV pair created in step 806. 

20 At step 813, data assembled at step 812B is encoded using well known 

techniques (preferably base-64), conq)leting assembly of tbe opaque section contents of 
message Rl. 

Message Rl is assembled at steps 814-818. At step 814, header 420S is 
created using the message template found at customer message template data structure 
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270 (Figure 5A) and a protocol number embedded in customer application software 210. 

Next at step 815, transparent label-vahie pairs 4213A-4213C as described 
above are appended. 

At step 816, opaque label-value pair 4217 is appended. Label-value pair 
4217 has the label "opaque** signifying that the vahie which follows is encrypted data. 
The value of label-value pair 4217, shown in Figure lOA, represents the data which was 
encoded at step 813. 

Trailer 4250 is assembled at step 817. The checksum of trailer 4250 is 
calculated as described above with respect to sample message 4000. Trailer 4250 is 
added to message Rl. At step 818, a copy of message Rl is saved in filed 251J. 

The assembly of message Rl is now complete. Message assembly process 
800 ends at step 819. 

Referring again to Figure 8, registration process 401 continues at step 
1204. There, customer computer 200 transmits message Rl to server computer 100. 
Customer computer 200 waits for a reply message R2 from server computer 100. 

At step 1205, server conqmter 100 receives message Rl from customer 
conq)uter 200 and unwraps message Rl by executing server message unwrap procedure 

900. Server message unwrap pn)ccdure 900 is now described wifli reference to Figures 
llA and IIB, where it begins at step 901. 

At step 901 A, a copy of message Rl is stored in field 140E (Figure 

4L). At step 902, server software 110 extracts the protocol number from field 

4205C of leader 4205 of message Rl. Next, based iq>on the protocol number extracted 

at step 902, server message data structure 150 (Figure 4A) is accessed to determine the 

expected format of message Rl . The expected format may include message syntax (e^, 
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pennitted end-of-line characters) and message coding (e.g., ASCII or hex). Message Rl 
is parsed in accordance with the expected format as follows. 

At step 903 server computer 100 calculates a checlcsum using the same 
data used by customer computer 200 at step 817 of message assembly procedure 800. 
5 At step 904, the checlcsum calculated at step 903 is compared to the checlcsum 42S0D 
of trailer 4250 of message Rl . If tte checksums are not equal, message Rl is discarded 
at step 904A where server message unwrap procedure 900 also terminates. 

If the checksums are equal at step 904, processing continues at step 906A 
where tte message is checked to determine if it is appropriate for message unwrap 
10 procedure 900. If a message includes a label "serverkey", message unwrap procedure 
900 is appropriate. Messages received by server computer 100 for which unwrap 
procedure 900 is inappropriate wiU not contain the "serverkey" label but will instead 
include a label "^pe" in the transparent part of die message. Such messages will be 
unwrapped using other procedures as described later. If a message is inappropriate, 
15 processing continues at step 906B where the message is diverted to anodier unwrap 
procedure. If message Rl is appropriate, therefore, processing continues at step 906C 
where the value of opaque label-value pair 4217 is decoded. 

At step 907, the RSA public key used by customer conqHiter 200 to 
encrypt the DES key/IV pair at step 806 of message assembly procedure 800 is 
20 determined. To do this, server software 110 obtains the vahie of label-value pair 4213C 
associated with the label "servetfcey". The vahie of label-vahie pair 4213C is a pointer 
to a field in private key data structure 160 which stores the RSA private key component 
corresponding to the RSA public key used by customer computer 200 at step 806. 

At step 909, the RSA private key determined at step 907 is used to 
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decrypt that portion of opaque label-vahie pair 4217 corresponding to the RSA-encrypted 
DES key/IV pair. In this manner, the DES key/IV pair used to encrypt the remainder 
of opaque label-vahie pair 4217 is obtained. At step 909A. it is determined whether the 
decryption of the DES key/IV succeeded or failed. Should the decryption faU for any 
5 reason, processing continues at step 905 where we have found it pieferable to set an 
^propriate error flag and server unwra?) procedure 900 terminates at step 917. If the 
decryption of the DES key/TV pair is successful, processing continues at step 910. 

At step 910. the DES key/IV pair obtained at step 909 is stored in a 
ten^nuy register. 

At step 911, the DES key/IV pair obtained at step 909 is used to decrypt 
that portion of opaque label-vahie pair 4217 revealing to label-value pairs 4217A-4217K 
of Figure lOB. At step 912, the decryption of die opaque-vahie pair 4217 is determined 
to either succeed or fiiil. Should the decryption £ail for any reason, processing continues 
at step 905 where we have found it preferable to set an appropriate error flag and server 
15 unwrap procedure 900 terminates at step 917. If the decryption of opaque-vahie pair 
4217 is successfiil. processing continues at step 913. 

At step 913, the message Qrpe is determined by reference to label-vahie 
pair 4217A. For example, die vahie of label-vatae pair 4217A for message Rl may be 
"registration.'' 

^° We ""ve found it preferable to have three checks of message Rl 

perframed at steps 914, 915 and 916 as follows: 

Server form check of step 914 is message type and software version 
dependem. That is. the expected form of die message, and the criteria that determine 
whedier it is acceptable, depend on die message and any variations of die message that 
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are valid at a given time as determined by reference to message type and version data 
structure ISO as previously described. At a minimum, the form check procedure will 
ascertain whether an incoming message contains all the labels that are prescribed for that 
message, whether there are values for each label that requires a value, and whether the 
5 values are of the type, syntax, and value range as required. If a message can be parsed 
but does not meet a fonn criteria, server computer 100 will set an error flag at step 90S 
and return an error code in message R2 (described later). A message which is so 
malformed that it cannot be parsed by server computer 100 will be discarded. If the 
form check at step 914 is successful, processing continues at step 91S. 

10 At step 91S, the digital signature represented by the value of label-value 

pair 4217K is verified (Pass signature test). First, server software 1 10 obtains the RSA 
public key for customer persona 120.1 firom the value of label-value pair 4217J. The 
RSA public key obtained from label-vahie pair 4217J is used to decrypt label-value pair 
42I7K. Next, server software 110 accesses message data structure ISO to detennine 

15 which label-value pairs were hashed at step 810 of message assembly procedure 800 to 
compute the value of label-value pair 42 17K. Server software 110 then hashes the same 
label-value pairs which were hashed at step 810. The two hash values are compared. 
If the hash values differ, an s^ropriate error flag is set at step 90S. In this case, server 
message unwr^ procedure 900 terminates at step 917. If the hash values match, 

20 processing continues at step 916. 

At step 916, a check as to whether customer application software 210 is 
current is performed as follows. Server software 110 obtains die version number of 
customer 2^1icati(m software 210 used to assemble message Rl from the value of label- 
vahie pair 4217C. Tte obtained vahie is con^>ared to die latest supported version 
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number of customer application software 210. 

Each version has associated with it one of three ^'status" labels. If the 
software check rcmms "current", then the customer application software 210 that 
constructed message Rl is the latest version of ttot software available. No flags are set 
and message unwr^ procedure 900 ends at step 917. If the software check returns 
"warning", the version of customer application software 210 is not tiie latest but is still 
deemed usable. A flag is set at step 905 which will cause a warning message to be sent 
to customer user 203 in message R2 (described below) and message unwrap procedure 
900 ends at step 917. If the label associated with customer plication software 210 is 
"fatal", the application software is not usable and an error flag is set at step 905 which 
will cause an error message to be sent to customer user 203 in message R2 (described 
below). Message unwrap procedure 900 ends at step 917, 

Referring again to Figure 8, processing continues at step 1206. If any of 
the tests of steps 909A, 912. 914, 915 or 916 caused an error flag to be set at step 905, 
error processing procedures arc executed by server computer 100 at step 1215. While 
the level of error processing at step 1215 is largely an administrative decision, it is 
preferred that a minimum, failures of the checksum, signature, and form, and a "fetal" 
return on the software check procedure result in a return message containing a code that 
can be processed by customer qyplication software 210 and a message that can be read 
by customer user 203, The error processing procedure in step 1215 entails associating 
a flag with a specific error code (described later in the context of die return message R2) 
and creating a text message (eidier from a data structure of messages or a message sent 
by the system administrator). Server cotqniter 100 tben generates a message R2 similar 
to that described later to customer computer 200 conveying the error code and any 
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related message. 

If the tests of steps 909A, 912, 914, 915 and 916 did not cause an error 
flag to be set at step 90S, processing continues at step 1207 where the vahie of label- 
value pair 4217F, is conq)ared to the persona id of field 120A for all customer personas 
5 120. 1 and field 120AA for all merchant personas 120.2 contained in server persona data 
structure 120. 

At step 1209, if unique, server software 110 creates a new persona 120. 1 
in server persona data structure 120. Information contained in message Rl is then 
transferred into the new persona 120.1 as follows: The value of label-value 4217F, and 
10 the two-digit check code, is assigned to the persona id of field 120A. The value of 
label-vahie pair 4217G, is stored in email address field 120B. The RSA public key of 
field 120C receives the value of labei-vahie pair 4217J. The vahie of lahel-vahie pair 
4217B is assigned to field 120D. The value of label- vahie pair 4217D is stored in field 
120E. The value of label-vataie pair 4217H is stored in field 1201. The vahie of label- 
15 vahie pair 42171 is stored in field 120F. In this case, processing continues at step 1217. 

If the valw of label-value pair 4217F is not unique to server persona data 
structure 120 at step 1207, processing continues at step 1216. 

At step 1216, a suggested persona id is determined by computing a 
random number and qypending it to the requested id widUTUt hyphenation. Thus, 
20 "Brian" becomes "BrianlS". In diis case, processing continues at step 1217. 

At step 1217, server software 110 assembles reply message R2, shown in 
Figure 13, according to the flow diagram of Figure 12. Figure 12 depicts server 
message assembly procedure 1000. 

Server message assembly procedure 1000 begins at step 1001. Steps 
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lOOlA-lOOlB create transparent label-value pair 4313 of message R2. Steps 1002-1009 
create opaque label-value pair 4317 of message R2. Steps 1010-1014 assemble header 
4305, transparent label-value pairs 4313A-4313C» opaque label-value pair 4317 and 
trailer 4350 of message R2. 

At step lOOlA, server software 110 accesses message data structure 150 
(Figure 4A) to obtain a list of labels, which, when matched up with associated values, 
make up the transparent label-value pairs 4313A-4313B of message R2 (Figure 13A). 
At step lOOlB, vahies are associated with each label as foUows: 

Label-value pair 4313A has the label "transaction". The value of label- 
value pair 43 13 A is a transaction number. The value of label-value pair 4313A is the 
same as that received in message Rl in label-vahie pair 4213A. 

Field 4313B has the label "date". The vahie of label-vahie pair 4313B is 
the same as that received in message Rl m label-vahie pair 4213B. 

Label-value pair 43 13C has the label"service<ategory". The value of 
label value pair 4313C is the same as that received in message Rl in label-value pair 
4213D. 

At step 1(X)2, server software 110 accesses message template data 
structure 150 to obtain a list of labels wbkh^ when matched up widi associated vahies, 
make up the opaque section contents of message R2, shown in Figure 13B. 

Processing continues at step 1005. There, values are matched up with 
labels to form label-vahie pairs 4317A-4317K, of Figure 13B. 

The opaque section contents of message R2 are shown in Figure 13B 
where label-value pair 4317A has the label "type". Label-vahie pair 4317A references 
a record in message data structure 150 which sets forth the labels of the opaque section 
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contents of message R2. The value of label-value pair 4317A is obtained from server 
software 110. 

Label- value pair 4317B has the label "server-date". The value of label- 
value pair 4317B indicates the date and time message R2 was assembled according to 
the clock of server computer 100. 

Label-value pair 4317C has the label "requested-id". The value of label- 
value pair 4317C indicates the persona id requested by customer user 203. The value 
of label-value pair 4317C was received in label-value pair 4217F in message Rl, 

Label-value pair 4317D has the label "response-id". The vahie of label- 
value pair 4317D indicates the persona id of customer user 203, or. if the requested-id 
in label-value pair 4317C was a duplicate, indicates a suggested persona id. 

Label-value pair 4317E has the label "email". The value of label-vataie 
pair 4317E indicates an email address for custon^r user 203. The vataie of label-value 
pair 4317E was received in label-vahie pair 4217G of message Rl. 

Label-vahie pair 4317F has the label "response-code". The value of label- 
value pair 4317F indicates ^ledier registration process 401 was a success or failure. 

Label-vahie pair 4317G has the label "funds-waiting". The vahie of label- 
value pair 4317G nidicates if there are any messages holding funds waiting for the holder 
of the email address in label-vahie pair 4317E. Alternatively, label-vahie pair could 
indicate the immber of such email messages. EiAer approach provides a means by 
which die registrant obtains any such fimds preferably requires the registrant to send 
server computer 100 a message containing a password provided by the sender of the 
funds. 

Label-value pair 4317H has the label "autoclose-passphrase". The vahie 
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label- value pair 4217H indicaies an autoclose passphrasc for customer user 203. The 
value of label-vahie pair 4317H was received in label-value pair 42171 of message Rl. 

Label-value pair 43171 has the label "pubkey". The value of label- value 
pair 43171 shown in Figure 13B represents the RSA public key of customer persona 
120. 1 received in label-value pair 4217J of message Rl. 

Label-value pair 431 7J has the label "swseverity" (software severity). The 
value of label-value pair 4317J indicates whether customer application software 210 
needs to be updated, but is still usable ("warning") or is no longer usable ("fatal"). The 
value of label-vahie pair 4317J is null if customer application software 210 is current. 

Label-value pair 4317K has the label "swmcssage" (software message). 
The value of label-value pair 4317K indicates instructions as to what customer user 203 
should do in the case of a "fiatal" or "warning" software severity. The vahie of label- 
value pair 4317K is only present if the value of labcl-vahie pair 4317J is not null. 

Label-value pair 43 17L has die label "message" . Tte vahie of label-value 
pair 4317L is a ftee text nwssage associated with an error or success condition returned 
in label-value pair 4317F and displayed to customer user 203. 

Referring again to Figure 12, processing continues at step 1007. There, 
label-vahie pairs 4317A-43 17L of Figure 13B are assembled and encrypted widi the DES 
key/TV pair decrypted at step 910. 

At step 1009, labcl-value pairs 4317A-4317L encrypted at step 1007 are 
encoded using well known techniques (preferably base-64). 

Message R2 is assembled at steps 1010-1014. At step 1010, header 4305 
is assembled using die message and type data structtire 150 and the protocol number 
ftbm the incoming message Rl . 
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Next, at step 1011, transparent label-value pairs 43 13 A and 4313B 
previously described are appended. 

At step 1012, opaque label-value pair 4317 is appended. Label- value pair 
4317 has the label "opaque" signifying that the value which follows is encrypted data. 
5 The value of label-value pair 4317 represents the data encoded at step 1009. 

Trailer 4350 is assembled (created) at step 1013. The checksum of trailer 
4350 is calculated as described above with respect to sample message 4000. Trailer 
4350 is appended to message R2. At step 1014, a copy of the complete message R2 is 
saved at field 140F of server message log data stnicnire 140. 
1 0 Tte assembly of message R2 has now been completed. Message assembly 

procedure 1000 ends at step 1015. 

Referring again to Figure 8, at step 1218, message R2 is sent (transmitted) 
from server computer 100 to customer computer 200. 

At step 1219, customer computer 200 receives message R2 from server 
15 conqniter 100 and unwraps message R2 by executing message unwrap procedure 1100. 
Message unwrap procedure 1100 is now described with reference to Figure 14, where 
it begins at step 1101. 

At step 1102, customer computer software 210 extracts the protocol 
(version) number firom header 4305 of message R2. Next, based upon the extracted 
20 protocol number at step 1102, message template data strucoire 270 (Figure 5A) is 
accessed to determine the cxpectod format of message R2. The expected format may 
include message syntax (e.g.. permitted end-of-Iine diaracters) and message coding 
fe.g. , ASCn or hex). Message R2 is parsed in accordance widi the expected format as 
follows. 
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At step 1103, customer con^ter 200 calculates a checksum using the 
same data used by server computer 100 at step 1013 of server message assembly 
procedure 1000. At step 1104. the checksum calculated at step 1103 is compared to the 
checksum of trailer 4350 of message R2. If the checksums are not equal, message R2 
5 is discarded at step 1104A where message unwrap procedure 1100 terminates. 

If the checksums are equal at step 1104, processing continues at step 
1105A where the message is checked to determine if it is appropriate for message 
unwrap procedure 1100. If a message does not include the label "type" in the 
transparent part of die message, message unwrap procedure 1100 is appropriate. 
10 Messages received by customer computer 200 containing the hibel "type" in the 
transparent part of tije message will be unwrapped using other procedures (described 
elsewhere) at step 1105B. Here, message R2 is appropriate; therefore, processing 
continues at step 1106 where die vahie of opaque label-vahie pair 4317 is decoded. 

At step 1107. die DES key/IV pair stored in temporary register at step 
15 802 of message assembly procedure 800 is retrieved. 

At step 1108, die DES key/IV pair retrieved at step 1107 is used to 
decrypt die vahie of opaque label-vahie pair 4317. If for any reason the decryption of 
opaque label-vahie pair 4317 is not success&l. step 1109 directs die processing of 
message R2 to step 1105 where anerror flag is seL In diis case processing of message 
20 unwrap procedure 1100 stops at step 1121. If die decryption of label-vahie pair 4317 
is successful, processing continues at step 1110. 

At stqi 1110, die message type is determined by reference to label-value 
pair 4317A. For example, vahie of label-vahie pair 4317A for message R2 may be 
"registration response. ' 
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A check of message R2 is then perfonned at step 1111 as follows. 
Message template data structure 270 (Figure 5A) contains data regarding the form of 
incoming messages. At a minimum, the form check procedure will ascertain whether 
an incoming message contains all the labels that are prescribed for that message, whether 
there are values for each label that requires a value, and whether the values are of the 
type (e.g. , text, signed numbers,), syntax (e.g. . in the form of a valid e-mail address) 
and within any specified limits as required. If there are additional labels, customer 
computer 200 wiU ignore them. If a message cannot be parsed, or if it can be parsed 
but does not me^ a form criteria, an error flag will be set at step 1105. 

If the message passes the form check at step 1111, message unwrap 
procedure 1100 terminates at step 1121. 

Referring again to Figure 8, processing continues at step 1220. There, 
we have found it preferable to handle error messs^es as follows: 

(1) if an error flag was srt at step 1105, the flag wiU be detected at 
step 1220 and processing of message R2 will terminate at step 1221. From the 
perspective of customer user 203, no further action is taken with respea to message R2. 
In die preferred embodiment of the present invention, we prefer to include a mechanism 
within customer application software 210 to create and send to server computer 100 a 
message. This message inctades the R2 message as received by customer computer 200 
and 2jxy diagnosis of what caused the message to fail. No response to this message is 
sent by servCTConqwter 100 to customer con^uter 200. Radier. the information is used 
to ascertain whediCT a problem exists within the system and if ^>propriate corrective 

measures need to be taken. 

(2) if no error flag was set at step 1105 but an error in message Rl 
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was detected at step 905 or step 1216, processing will continue at step 1222 where the 
content of label-value 4317F is checked. If the value of label-value 4317F is other than 
'success", error processing routines are performed at step 1223 causing customer 
application software 210 to display the message contained in label-value 4317K 
5 associated with the content of label-vahie 43 17F and to interpret the value of label-value 
4317F and take whatever action may be associated with that value. In particular, if the 
only error flag set was detected at step 1216 indicating that the requested id was not 
unique, the id suggested by server computer 100 and returned in label-value pair 4317D 
is displayed and the registration process is restarted at step 1201; or 
^° (3) if message Rl passed die check at step 905 and no flags were set 

at step 1105 and the id requested by customer user 203 was accepted by server computer 
100, processing continues at step 1224 where customer application software 210 updates 
customer database 202 as foUows: The vahie of label-vahie 4317D and the two-digit 
check code is assigned to die customer persona id of field 220A. The vahic of label- 
15 vahie pair 4317E is stored in die email address of field 220B. The RSA public key of 
field 220C receives die vahie created by customer application software 210 and echoed 
in label-vatae pair 43171. In addition, record 261 of customer log data strucoire 260 is 
created as foUows: The transaction number from label-vahie pair 4313A is stored in field 
261B. The date from label-value pair 4317B is stored in field 261C. TTie requested id 
20 from label-vahie pair 4317C is stored m field 261H. TTie response id from label-vahie 
pair 4317D is stored m field 2611. The email address fixim label-vahie pair 4317E is 
stored in field 261J. The response-code from label-vahie pair 4317F is stored in field 
261F. TTie software severity code ftom label-vahie pair 4317J is stored in field 261D. 
The software-message from label-vahie pair 4317K is stored in field 261E. The 
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response message associated with the response code from field 4317L is stored in field 
261G. 

Processing continues at step 1225 where registration process 401 ends. 
C. Instrument Binding Process 403 
5 Instniment binding process 403 is a process by which a customer 

user 203 binds an instrument to customer persona 120.1. Figure 15 depicts a flow 
diagram illustrating instrument binding process 403 which begins at step 1301. 

At step 1302, customer application software 210 prompts (request) 
customer user 203 to enter infomiation relating to an instrument to be bound to customer 

10 persona 120.1. This information will be included in message BIl sent to server computer 
100 and will become part of instrument binding data 120H (fields 120H. 1-120H.28) for 
the instrument being bound. In die prefierred embodiment, customer user 203 enters the 
instrument number, the instrument e;q)iration date, the instrument customer identi fi cation 
number, and the name, street address, city, state, postal code, country, countty code, 

15 and the telephone iiumber (iiichiding area code) of the instrument holder. Gistomeruser 
203 will also be asked to indicate whether the instrument being bound is the autoclose 
instrument as previously described. In addition, cu^omer application software 210 wiD 
create a random number (referred to as "instrument salt"). Customer user 203 will also 
be asked for a descrqition of the instrument being bound. This description might be in 

20 the form of 'Qmqony Credit Card" or "John's Bank Account." For bindings of credit 
cards, this information is stored in field 252R in customer pending transaction data 
structure 250. Instrument type, instrument category, and instrument functions are 
derived by customer application software 210 frwn the data entered by customer user 
203. 
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WhUc the data acquired at step 1302 is described with reference to a credit 
card instmment, it is within the knowledge of one skiUed in the art to modify the credit 
card data to accommodate debit cards, DDAs, and other financial instnaments. 

Message BIl will be assembled by and transmitted from customer 
computer 200 to server computer 100 to effea instrument binding process 403. The 
contents of the message BIl in now described with reference to Figures 16A and 163. 

Label-value pair 4413A has die label "id". The value of label-value pair 
4413A indicates the persona id for customer user 203. The vahie of label-vahie pair 
4413A is obtained from field 220A of customer persona data structure 220 (Figure 5B). 

Label-value pair 4413B has the label "transaction". The value of label- 
value pair 4413B is a transaction number, generated by customer application software 
210, which uniquely identifies message BIL The vahic associated with label-vahie pair 
4413B is stored in field 252B (Figure 5H). 

Label-value pair 4413C has the label "date". The vahie of label-value pair 
4413B indicates the date and time that message BIl was assembled and sent to server 
con^niter 100, according to the clock of customer COTaputer 200. The value associated 
with label-vahie pair 4413C is stored in field 252C of customer pending data structure 
250. 

Label-vahie pair 4413D has tbe label "servericey " . As described later, the 
DES kcy/IV pair used by customer computer 200 to encrypt opaque label-value pair 
4417 of message BIl is encrypted using an RSA public toy of server computer 100. 
The value of labcl-vahie pair 4413D points to the corresponding RSA private key stored 
in server private key data structure 160. 

Label-value pair 4413E has the label "service-category". The value of 
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label-value pair 4413E is a label which may be used to route message BIl to a processor 
within server computer 100 that handles messages of a particular service category. 

Label-value pair 4417 has the label "opaque** signifying that the date 
which follows includes the encrypted opaque section contents of message BIl. 

The opaque section contents of message BIl , shown in Figure 16B, is now 

described. 

Label-value pair 4417A has the label '*type". The value of label-value 
pair 4417A references a record in message data structure 270 (Figure 5A) which sets 
forth the labels of the opaque section contents of message BIl. The value of label-value 
pair 4417A is obtained from customer application software 210 which generates the 
vahie when customer user 203 initiates the instrument binding process 403. 

Label-value pair 4417B has die label ''server-date". Label-value pair 
4417B indicates the date and time message BIl was assembled as measured by customer 
computer 200*s perception of server computer lOO's clock. 

Label-value pair 4417C has the label "swversion" (software version). The 
value of label-value pair 4417C indicates die version of customer application software 
210 communicating with server computer 100. The vahie of label-value pair 4417C is 
obtained firom data embedded in customer application software 210. The value associated 
widi label-vahie pair 4417C is stored in field 252D (Figure 5H). 

Label-value pair 4417D has the label "instrument-number" . For securi^ 
reasons, die actual mstrument number is not stored in database 102 of server computer 
100. Rather, the instrument number is stored in database 102 as a hash value The hash 
of the value associated with label-value pair 4417D is stored in field 2S2F. 

Label-value pair 4417E has the label "mstrument-type". Label-vahie pair 



72 



4417E indicates a type of instrument, for example, VISA, MasterCani, American 
Express, etc. The value of label-value pair 4417E is obtained from customer user 203 
during instnimem binding process 403 at step 1302 or may be derived by customer 
application software 210 from the instrument number. The value associated with label- 
5 value pair 4417E is stored in field 252T. 

Label-value pair 4417F has the label "instrument-category". The value 
of label-vahie pair 4417F indicates a category of the instrument being bound. Categories 
may inchide, for example, credit cards, debit card. DDAs, etc. The value of label-value 
pair 4417F is derived by customer application software during instrument binding 
10 process 403 at step 1302. 

Label-vahie pair 44171 has the label "instrument-ftmctions' and preferably 
may have any combination of the following values: "charge", "credit", "load" or 
"unload" . The value of label-vahie pair 44171 indicates one or more functions that may 
be performed by custcwner user 203 with the instrument being bound. A charge 
15 transaction occurs when a persona 120.1 uses a bound instrument as a credit card to pay 
for a product. A credit transaction is an operation where a merchant credits customer 
persona 120.1 in lieu of providing the product originally agreed upon. The load and 
unload transaction are the same as those described previously. The function(s) of label- 
value pair 44171 are derived by customer plication software 210 during instrument 
20 bindii^ process 403 at step 1302. 

Label-value pair 4417J has ibt label "instrument-salt" . The value of label- 
value pair 4417J indicates a cryptognq>hic salt used to reduce the ease by which die 
vahie of label value pair 4417D (relating to the instrument number) can be determined. 
the vahjc of label value pair 4417J is generated by customer application software 210 
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during instiument binding process 403 at step 1302. The value associated with label- 
value pair 4417J is stored in field 252U (Figure 5H). 

Label-value pair 4417K has the label "instrument-expiration-date". The 
value of label-value pair 4417H indicates the expiration date of the instrument being 
5 bound. The value of label-value pair 4417K is obtained from customer user 203 during 
instrument binding process 403 at step 1302. The value associated with label-value pair 
4417K is stored in field 2S2I. 

label- value pair 4417L has the label "in^rument-name**. The vabie of 
label-value pair 4417L indicates the name of the holder of the instrument being bound. 
10 The value of label value pair 4417L is obtained from customer user 203 during 
instrument binding process 403 at step 1302. The vahie associated widi label-value pair 
4417L is stored in field 2S2H. 

Label-vahie pair 4417M has the label "instrument-address**. The value 
of label-value pair 4417M indicates the street address of the holder of the instrument 
15 being bound. The value of label-value pair 4417M is obtained from customer user 203 
during instrument binding process 403 at step 1302. 

Label-value pair 4417N has the label "instrument-city". The value of 
label-vahie pair 4417N indicates the city of the holder of the instrument being bound. 
The value of label-value pair 4417N is obtained from customer user 203 during 
20 instrumem binding process 403 at step 1302. 

Label-value pair 44170 has the label 'instnunent-state*. The value of 
label-vahie pair 44170 indicates the state of the holder of the instrument being bound. 
The vahie of label-value pair 44170 is obtained from customer user 203 during 
instrument binding process 403 at step 1302. 
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Label-value pair 4417P has the label "instnnnem-postal-code". Label- 
value pair 4417P indicates the postal code of the holder of the instrument being bound. 
The value of label-value pair 4417P is obtained from customer user 203 during 
instrument binding process 403 at step 1302. 

Label-vahie pair 4417Q has the label "instrument-country" . The value of 
label-value pair 4417Q indicates the country of the holder of the instrument being bound. 
The value of label-value pair 4417Q is obtained from customer user 203 during 
instrument binding process 403 at step 1302 

The value associated with label-value pairs 4417K-4417Q are stored in 
fields 252H-252N (Figure 5H). 

Label-value pair 4417R has the label "agreements". Label-value pair 
4417R iiylirafejii which legal agreements customer user 203 has accepted in order to use 
the present invention. The value of label-value pair 4417R is generated ftom agreement 
accepted by custt)mer user 203 and stored in field 230S (Figure SD). 

Label-vahie pair 4417S has the label 'autoclose' and may have the vahie 
"yes" or "no". The value of label-value pair 4417S indicates whether the instrument 
beiiigbouTKi wiU be the autocloseiiistnmient for customer user 203. The value of label- 
value pair 4417S is obtained from customer user 203 during instrument binding process 
403 at step 1302. 

Label-vahie pair 4417T has the label "autoclose-passphrase". The vahie 
of label-vahie pair 4417T iixiicates the passphrase (preferably six to fifty characters) 
which, when used, will close customer persona 120. 1 . Label-vahie pair 4417T is presem 
only if d« vahie of label-vatae pair 4417T is "yes". The vahie of label-vahie pair 4417T 
is provided by customer user 203 during registration process 401. 
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Label-value pair 4417U has the label "key". The value of label-value pair 
4417U represents a bash of the modulus part of the RSA public/private key pair for 
customer persona 120.1. The value of label-value pair 4417U permits server computer 
100 to confirm that the RSA public key maintained in field 120B (Figure 4B) is the same 
5 key used to sign message BIl (label-vahie pair 4417V), 

The digital signature of message BIl, represented by label- value pair 
4417V, has the label "signature". The value of label-vahie pair 4417V represents the 
digital signature of customer persona 120.1. For message BIl, the value of label-value 
pair 4417V is preferably a hash of label-vahie pairs 4413A-4413D, and label-value pairs 

10 4417A-4417U in alphabetical order, encrypted with the RSA private key of customer 
persona 120.1. The RSA private key of customer persona 120.1 is obtained from field 
220H (Figure 5Q. 

Referring again to Figure IS, at step 1303, message BIl is assembled m 
accordance with message assembly procedure 800, depicted in Figure 9. Message 

IS assembly procedure 800 was described previously for the assembly of registration 
message Rl. widi tbs following modification noted for message BIl: A copy of mess^e 
BIl is preferably saved in field 2S2W (Figure SH) instrument binding process 403 
continues at step 1304. There, customer computer 200 transmits message BIl to server 
coitqHiter 100. Customer computer 200 waits for reply message B14 from server 

20 computer 100. 

At step 1305, server computer 100 receives message BIl from customer 
computer 200 and unwnq>s message BIl by executing server message unwrq) procedure 
900 (steps 901-917). Server message unwrap procedure 900 (steps 901-917) was 
previously described with reference to Figure 11 for message Rl. 
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At step 1306. if any of the tests of steps 909A, 912, 914. 915 or 916 
caused an enor flag to be set at step 905. enor processing procedures are executed by 
server computer 100 at step 1313. 

While the level of error processing at step 1313 is largely an 
5 administrative decision, it is preferred that a minimum, failures of die checksum, 
signature, and fonn. and a "fatal" redim on the software check procedure result in a 
return message containing a code diat can be processed by customer application software 
210 and a message that can be read by customer user 203. The error processing 
procedure instep 1313 entails associating a flag widi a specific eiror code (described in 
10 the context of the reoim message BI4 below) and creating a text message (eitiier ftom 
a data structure of messages or a message sent by die system administrator). Server 
computer 100 then sends a message BI4 similar to that described later to customer 
con^juter 200 conveying die errw code and aiqr related message. 

If the tests of steps 909A, 912. 914. 915 and 916 did not cause an error 
IS flag to be set at step 905, processing continues at step 1307. There, information 
contained in message BIl is transfctred into die instrument binding data 120H (fieWs 
120H. 1-120H.28) (Figure 4D) as foUows: The vahie of label-value pair 4413A is stored 
in die persona id of field 120H.1. The value of label-vahie pair 4417A is stored in die 
instrument type of field 120H.2. TTie vahie of label-value pair 4417B is stored in die 
20 instrument bind date of field 120H.13. If die instrument being bound is selected by 
customer user 203 as die autoclose instrument die vahie of label-value pair 4417D is 
stored in die instrument number of field 120H.4. It is prefened diat diis value be 
encrypted using an RSA key known only to die system operator. If die instrument being 
bound is not die autoclose instrument of die persona, die vahie of label-value pair 4417D 
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is not stored at server data structure 102 but is hashed along with the value in label-value 
pair 4417J and stored in the instrument bash of field 120H.9. The vahie of label-value 
pair 4417E is stored in the instrument sub type of field 120H.3. The value of Ubel-value 
pair 4417F is stoied in the instrument type of field 120H.2. The value of label-vahie pair 
4417R is stored in the legal agreements of field 120H.7. The value of label-value pair 
4417S is stored in the autoclose binding of field 120F. 

After step 1307, message BI4 will be assembled by and transmitted from 
server computer 100 to customer computer 200 to complete instrument binding process 
403. The contents of die message BI4 is now described wi* reference to Figures 17A 
and 17B. 

Label-valuepair44.113Ahas the label "id". The value of label-vahie pair 
44.113A indicates the persona id for customer user 203. The vahie of label-value pair 
44.113A is the same as that received in message BIl in label-vahie pair 4413A. 

Label-vahic pair 44. 113B has the label "transaction" . The vatae of label- 
vahie pair 44.11 3B is a transaction number. The value of label-vahie pair 44. 113B is 
the same as fliat received in message BIl m labd-vahie pair 4413B. 

Field 44.113C has flie label "date". The vahie of label-vahie pair 
44.113C is the same as that received in message BIl in label-value pair 4413C. 

Label-vatae pair 44. 113D has the label "service-category". The value of 
labd-vahie pair 44.113D is die same as dial received in message BIl in label-vahie pair 
4413E. 

The opaque section contents of message BI4, shown in Figure 17B, is now 

described. 

Label-value pair 44.117A has die Ubel "type". The value of label-vahie 
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pair 44.117A references a record in message data structure 270 (Figure 5A) which sets 
forth labels of the opaque section contents of message BI4. The value of label- value pair 
44.117A is obtained from server software 110. 

Label-value pair 44. 1 17B has the label 'server-date" . The value of label- 
5 value pair 44.117B indicates the date and time message BI4 was assembled according 
to the clock of server computer 100. 

Label-vahie pair 44. 1 17C has the label "response-code* and preferably the 
vahie "success" or "failiu«". The value of label-vahie pair 44. 117C indicates whether 
ixsstrument binding process 403 was a success or failure. 
10 Label-vahie pair 44.117D has the label "swseverity" (software severity) 

and preferably the value "fatal" or "warning". The value of label-value pair 44.117D 
indicates whether customer application software 210 needs to be upda»l, but is still 
usable ("warning") or is no longer usable ("fetal"). The value of label-vahie pair 
44.117D is null if customer application software 210 is current. 
1 5 Label-value pair 44. 1 17E has the label "swmessage" (software message) . 

The value of label-vahie pair 44.1 17E provides instructions as to what customer user 203 
should do in tte case of a "fatal" or "warning" software severi^. Tte vahie of label- 
vahie pair 44.117E is only present if the value of label-vahie pair 44.117D is not null. 

Label-vahie pair 44. 1 17F has the label "mstrument-number " . The vahie 
20 of label-vahie pair 44.117F indicates Ae number of the instrument being bound as 
described above. The vahie of label-vahie pair 44.1 17F is obtained from label-value pair 
4417D of message BIl. 

Label-value pair 44. 117G has the label "ixBtrumenl-type". The value of 
label-vahie pair 44.117G indicates a type of instrument. The value of label-value pair 
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44, 1 17G is obtained from label-value pair 4417E of message BIl . 

Label-value pair 44. ilTH has the label "instiument-salt". The value of 

label-value pair 44.117H from label-value pair 4417J of message BIl. 

Label-value pair 44.1 17J has the label -instrument-functions'* and may 

have any combination of the foUowing values: "sale", "credit", "load" or "unload" as 

previously described. Label-value pair 44. 1 17J indicates oi» or more functions that may 
be performed by customer user 203 with the instrument being bound. The value of 
label-value pair 44.1171 is obtained from label-value pair 44171 of message BIl. 

Label-vahie pair 44.1 17K has the label "instrument*" and represents any 
number of label-value pairs whose labels start with "instrument" that are provided to 
customer user 203 in message BI4 (as previously described) and returned to server 
computer 100 in message LUl when the instrument is used to load or unload funds. In 
this way, server computer 100 may receive information regarding the instrument when 
necessary without storing that information in its data structures. The particular data- 
vahic pairs that are contained in label-vahie pair 44.117K depend on the type of the 
bound instrument and the requirements of the issuer of the instrument. For exan^le, 
a credit card might require the card number, die card e;q)iration date, and the name and 
address of the card holder to be returned to the server each time die card is used to load 
funds into person 120.1. 

Label-value pair 44.117L has the label "message". The value of label- 
value pair 44.117L is a free text message associated widi an error or success condition 
r«umed in labelvahie pair 44.117C and displayed to customer user 203. The value of 
label- value pair 44. 117L may iKlude a message indtcaring a bad digital signaoire or an 
ill formed registration message BIl and instructions as to how customer user 203 should 
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proceed (e.g. . "call system administrator"). 

Referring again to Figure 15, at step 1308A, message BI4 is assembled 
in accordance with server message assembly procedure 1000, depicted in Figure 12. 
Server message assembly procedure 1000 was described previously for the assembly of 
5 registration message R2. At step 1308B, message BI4 is sent to server computer 100. 

At step 1309, customer computer 200 receives message BI4 from server 
computer 100 and unwraps message BI4 by executing message unwrap procedure 1 100 
(steps 1101-1121). Message unwr^ procedure 1100 was previously described with 
reference to Figure 14 for message R2. 

10 At step 1310, 

(1) if an error flag was set at step 1105, the flag wiU be detected at 
step 1310 and processing of message BI4 will terminate at step 1311. From the 
perspective of customer user 203, no further action is taken with respect to message BI4. 
In the present invention, a mechanism is provided within customer application software 

15 210 to create and send to server compute 100 a message. This message ixx:ludes the 
BI4 message as received by customer computer 200 and any diagnosis of wbzx caused 
the message to fail. No response to diis message is sent by server computer 100 to 
customer conpiter 200. Rather, the information is used to ascertain whether a problem 
exists widiin the system and if appr o pri ate corrective measures need to be taken. 

20 (2) if no error flag was set at step 1105 but an error in message BIl 

was detected at step 905, processing will contimie at sbsp 1312 where the content of 
label-vahie 44.117C is checked. If the vahie of label-value 44.117C is other than 
"success*, error processing routines are performed at step 1314 causing customs: 
application software 210 to display the message contained in label-value 44.117L 
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associated with the content of label-value 44.117C and the interpret the value of label- 
value 44.117C and take whatever action niay be associated with that value; or 

(3) if message BIl passed the check at step 905 and no error flags 
were set at step 1105, processing continues at step 1315 where customer application 
5 software 210 updates customer database 202 as follows: The instrument number from 
label-value pair 44, 1 17F is stored in field 230A (Figure 5D). The content of label-value 
pair 44.117J is used to set flags in fields 230L-230O. The result code contained in 
label-value pair 44. 1 17C is saved in field 230P. The content of label-value pair 44. 1 17K 
is stored in field 230IL In addition, a new record 262 (Figure 50) of customer log data 
10 structure 260 is created as follows: The transaction number from label-vahie pair 
44.113B is stored in field 262B. The date from label-value pair 44.117B is stored in 
field 262C. The response-code ftx)m label-value pair 44.117C is stored in field 262F. 
The software severity code from label-vahie pair 44. 1 17D is stored in field 262D. The 
software-message from label-vahie pair 44.117E is stored in field 262E. The 
15 instrument-number from label-value pair 44.117F is stored in field 2621. The 
instrument-type from label-value pair 44.117G is stored in field 262J. The response 
message associated with the response code from field 44.117L is stored in field 262G. 

Processing continues at stq> 1316 where instrument bitKiing process 403 

ends. 

20 LoadAJnloftd Fpn^ ^ 

Figure 18 depicts a flow diagram illustrating load/unload process 405 
which begins at step I40L 

At step 1401A, customer user 203 selects whether customer user 203 
d^ires to load or unload (operation) funds. For the purposes of this description, it is 
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assumed that customer user 203 selects to load fimds. Unloading funds foUows the same 
process with the exception that ftmds to be unloaded are specified as a negative quantity. 

At step 1402. customer application software 210 accesses field 230O of 
record 230.1 for all instruments bound to persona 120.1 and displays a list of all 
5 instrumems enabled for load operations. At step 1403. customer user 203 is prompted 
select an instrument from the displayed list from which to load funds into cash container 
represented by cash container data fields 120G and 2201. 

At step 1406. customer user 203 is prompted (requested) to enter an 
amount of funds in a specified currency to load from instrument selected at step 1402 
10 into cash container 120G. 

Message LUl will be assembled by and transmitted from customer 
computer 200 to server computer 100 to effect load/unload funds process 405. Tbc 
contents of the message LUl is now described widi reference to Figures 19A and 19B. 

Label-vahie pair 4513A has the label "id". Label-vahie pair 4513A 
15 indicates dK persona id for customer user 203. The vahie of label-value pair 4513A is 
obtained from field 220A (Figure 5Q. TTievatoie associated with label-value pair 4513A 
is stored in field 255E (Figure 5K). 

Ubel-value pair 4513B has the label "transaction". ITje value of label- 
vahie pair 451 3B is a transaction mmiber. generated by customer application software 
20 210. which uniquely identifies message LUl. IT* vatae of label-value pair 4513B allows 
server computer 100. upon receipt of message LUl.(l) to send an associated reply 
message LU2. described later, and (2) to detennine if message LUl is a duplicate 

message 0^. already received by server computer 100). The value associated with 
label-value pair 4513B is stored in field 255B. 
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Label-value pair4513C has the label ''date". The vahie of label-value pair 
4513C indicates the date and time that message LUl was assembled and sent to server 
computer 100, according to the clock of customer con^)uter 200. The value associated 
with label-value pair 4513C is stored in field 255E. 

Label-value pair 4513D has the label •'serverkey^ As described below, 
the DES key/IV pair used by customer computer 200 to encrypt the opaque label-value 
pair 4517 of message LUl is encrypted using an RSA public key of server computer 
100. The value of label-vahie pair 4513D points to the corre^nding RSA private key 
stored in server private key data structure 160. 

Label-value pair 4513E has the label "service-category". The value of 
label-value pair 4513E is a label which may be used to route message LUl to a 
processor within server computer 100 that handles messages of a particular service 
category. 

Label-value pair 4517 has the label "opaque" signifying Aat die data 
which follows includes the encrypted opaque section contents of message LUl. The 
opaque section contents of message LUl. shown in Figure 19B, is now described. 

Label-value pair 4517A has the label "type". The vahic of label-value 
pair 4517A rcfeicnces a record in message data structure 150 (Figure 4A) which sets 
fordi the labels of the opaque section contents of message LUl. The value of label-vahie 
pair4517A is obtained from customer application software 210 which generates the label 
when customer user 203 initiates the load/unload process 405. 

Labcl-vatae pair 4517B has the label "scrvcr-daie". The vahie of label- 
value pair 4517B indicates the date and time message LUl was assembled as measured 
by customer computer 200*s perception of server computer lOO's clock. 
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Label-value pair 4517C has the label "swversion" (software version). The 
value of label-value pair 4S17C iixlicates the version of customer application software 
210 communicating with server computer 100. The value of label-value pair 45 17C is 
obtained from data embedded in customer application software 210. The value associated 
5 with label-value pair 4517C is stored in field 255D (Figure 5K). 

Label-vahie pair 4517D has tte label "amount". The value of label- value 
pair 4S17D represents the currency type aiKl the amount of funds to be transferred fh)m 
the bound instrument selected at step 1402 to the cash container 120G for customer user 
203. For unload operations, the amount of funds is a negative quantity. Thus, for 
10 unloads, the value of label-value pair 4S17D represents the currency type and the amount 
of funds to be transferred from cash container 120G to the bound instrument selected at 
step 1402. The vahie associated with label-valtie pair 4517D is stored in field 2SSG. 

Label-value pair 4S17E has the label "instrument*" and represents all of 
the label-value pairs returned by server computer 100 in message BI4 in label-value pair 
15 44.117K (Figure 17A) whose labels start with "instrument". The value of label-vahic 
pair 4S17E is unique to the instrument from which the load operation is to be performed 
and identifies Aat instrument to server conqnifer 100. 

Label-vatuepair4S17F has the label "key". The value of label-value pair 
4S17K represents a hash of the modulus part of the RSA public/private key pair used by 
20 customer persona 120. 1. The vahie of label-vahie pair 4517F permits server computer 
100 to confirm that the RSA public key maintained in field 120B (Figure 4B) is the same 
key used to sign message LUl (label-vahie pair 4S17F). 

Referring again to Figure 18, at step 1407, message LUl is assembled in 
accordance with message assembly procedure 800 (Figure 9). Message assembly 
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procedure 800 was described previously for the assembly of registration message Rl, 
with the following modification noted for message LUl. A copy of message LUl is 
preferably saved in field 140E (Figure 4L). 

Load/unload process 40S continues at step 1408. There, customer 
5 computer 200 transmits message LUl to server computer 100. Customer computer 200 
waits for a reply message LU2 from server computer 100. 

At step 1409, server conqmter 100 receives message LUl fi-om customer 
computer 200 and unwraps message LUl by executing server message unwrap procedure 
900 (steps 901-917). Server message unwrap procedure 900 was previously described 
10 with reference to Figure 11 for message Rl. 

Referring again to Figures UA and UB, processing continues at step 
1410. if any of the tests of steps 909A. 912. 914, 915 or 916 caused an error flag to be 
set at step 90S, error processing procedures are executed by server computer 100 at step 
1417. While die level of error processing at step 1417 is largely an administrative 
15 decision, it is preferred that a minimum, failures of the checksum, signature, and form, 
and a "fatal" return on the software check procedure result in a return message 
containing a code diat can be processed by customer application software 210 and a 
message that can be read by customer user 203. The error processing procedure in step 
1417 entails associating a flag with a ^ific error code (described in the context of the 
20 return message LU2 below) and creating a text mess^e (either from a data structure of 
messages or a messs^ sent by the system administrator). Server computer 100 dsen 
generates a message LU2 similar to diat described below to customer computer 200 
conveying die error code and any related message. 

If the tests of steps 909A. 912. 914. 915 and 916 did not cause an error 
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flag to be set at step 90S, processing continues at step 1411. There, information 
contained in message LUl, that is, the amount represented by label-vahie pair 4S17D, 
is updated to the amount in the cash container of field 120G.2 of persona 120.1 for 
customer user 203 in server persona data structure 120. At this point, server computer 
5 100 will cause funds from the instrument referenced in the message LUl to be 
transferred the agency account identified in cash container field 120G.4. Funds requested 
in message LUl may be placed *'on*hold'' in such a way that they are not available imtil 
some additional conditions have been met, such as twenty-four hours having elapsed. 

After step 1411, message LU2 will be assembled by and transmitted from 
10 server computer 100 to customer computer 200 to complete load/unload funds process 
40S. The contents of the message LU2 is now described with reference to Figures 20A 
aiid20B. 

Label-vahie pair 45. 113A has the label "id**. The value of label-value pair 
45. 1 13A indicates the persona id for customer user 203. The vahie of label-value pair 
15 4S.113A is the same as that received in message LUl in label-vahie pair 4513A. 

Label-value pair 45. 113B has the label "transaction* . The value of label- 
value pair 45. 113B is a transaction number. The value of label-vahie pair 45. 1 13B is 
the same as that received in message LUl in label-vahie pair 4513B. 

Label-vahie pair 45.113C has the label "date". The vahie of label-value 
20 pair 45.113C is the same as that received in message LUl in label-value pair 4513C. 

Label-vahie pair 45. 113D has the label "service-category". The vahie of 
label-vahie pair 45.113D is tbc same as that received in message LUl in label-vahie pair 
4513E. 

The op&que section contents of the reply message LU2, shown in Figure 
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20B, is as foUows: 

Label-value pair 45. 1 17A has the label " type* . Label-value of label- vahie 
pair 45. 1 17A references a record in message data structure 270 (Figure 5A) which sets 
forth the labels of the opaque section contents of message LU2. The value of label-value 
pair 45. 11 7A is obtained from server software 110. 

Label-value pair 45.U7B has the label "server-date". Label-value pair 
45.117B indicates the date and time message LU2 was assembled according to the clock 
of server conq)uter 100. 

Label-vahie pair 45-1 17C has the label "amount". The value of label- 
value pair 45.117C is the amount transferred from the bound instrument identified by 
label-value pair 4517E to cash contauwr field 120G.2 for customer user 203. 

Label-value pair 45.117D has the label "re^nse-code" and the vatee 
"success" or "failure" as previously described. Label-value pair 45.117D tiKfic^Tcs 
whether loadAmload process 405 was a success or feilure. 

Label-value pair 45.117E has the label "message". The value of label- 
value pair 45. 1 17E is a free text message ejq)laining the "response-code" valxze of label- 
value pair 45.1 17D- 

Label-vatue pair 45.117F has the label "swseverity" (software severity) 
and the value "&tal" or "warning". The value of label-value pair 45.117F indicates 
^Aiether customer application software 210 needs to be updated, but is still usable 
("warning") or is no longer usable ("fatal"). The vahie of label-value pair 45.117F is 
null if customer application software 210 is current 

Label-value pair 45.117G has the label "swmessage" (software message). 
The value of label-value pair 45.117G indicates instnictions as to what customer user 
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203 should do in the case of a "fatal" or "warning" software severity. The value of 
label-value pair 45.1 17G is only present if the value of label-value pair 45.117D is not 
null. 

Label-value pair 45.117H has the label "fee". The value of label-value 
5 pair 45. 117H indicates a fee charged to customer user 203, if any, associated with server 
computer 100 processing message LUl. The fee, if any, will be deducted from cash 
container field 120G.2. 

Label-vahie pair 45. 1 171 has the label "balaxKie" . The value of label-value 
pair 45*1171 indicates the available balance in cash container field 120G.2 for customer 
10 user 203. This balance reflects the previous balance of the cash container adjusted by 
the amount value of label- value pair 45. 117C loaded via message LUl and die fee value 
of label-value pair 45.117H. 

Label-vahie pair 45.117J has the label "session-fimds". The value of 
label-vahie pair 45.117J indicates the amount transferred from cash container field 
15 120G.2 to die opening amount field 130E of server session data structure 130 for all 
open sessions. 

Label-value pair 45.117K has the label "on-hoki". The vahie of label- 
vahie pair 45.117K is obtained from cash container field 120G.3 and indicates the 
amount of funds pending transfier from the bound instzument identified by label-vahie 
20 pair 4517E of message LUl to cash container field 120G.2 for customer user 203. This 
vahie represents funds which are awaithag ^)provai or processing by the issuer of the 
instrument from which fimds are being loaded or to which fiinds are being unloaded. 

At step 1412 of Hgure 18, server software 110 assembles reply message 
LU2 according to the flow diagram of Figure 12. Server message assembly procedure 
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1000 was described previously for the assembly of registration message R2. 

Referring again to Figure 14 message LU2 is sent from server computer 
100 to customer computer 200 at step 1412A. 

At step 1413, customer computer 200 receives message LU2 from server 
computer 100 and unwraps message LU2 by executing message unwrap procedure 1 100 
(steps 1101 - 1121). Message unwrap procedure 1100 was described previously with 
reference to Figure 14 for message R2. 

At step 1414, 

(1) if an error flag was set at step llOS, the flag will be detected at 
step 1414 and processing of message LU2 will terminate at step 1415. From the 
perspective of customer user 203, no further action is taken widi respect to message 
LU2. In the present invention, a mechanism is provided within customer application 
software 210 to create and send to server conq)uier 100 a message. This message 
inchides the LU2 message as received by customer computer 200 and any diagnosis of 
what caused the message to fail. No response to this message is sent by server conqmter 
100 to customer computer 200. Rather, the information is used to ascertain whether a 
problem exists within the system and if q>propriate corrective measures need to be 
taken. 

(2) if no error flag was set at step 1105 but an error in message LUl 
was detected at step 905, processing will continue at step 1416 where the content of 
label-vahie 45.117D is checked. If the value of label-vahie 45.117D is other than 
"success*, error processing routines are performed at step 1418 causing customer 
application software 210 to display the message contained in label-value 45.117E 
associated with the content of label-vahie 45. 117D and to interpret the value of label- 
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value 45. 1 17D and take whatever action may be associated with that vahie; or 

(3) if message LUl passed the check at step 905 and no flags were set 
at step 1105. processing continues at step 1419 where customer application software 210 
updates customer database 202 by storing the content of cash container field 220J of 
5 customer persona data structure 220. 

In addition, a ikw record 264 of customer log data strucnire 260 is 
created as follows: The persona id from label-value pair 45. 113 A is stored in field 
264H. The transaction number from label-value pair 45.113B is stored in field 264B. 
The date from label-value pair 45. 1 17B is stored in field 264C. The amount from label- 
10 vahie pair 45.117C is stored in field 264J. The response-code from label-value pair 
45.117D is stored in field 264F. The req)onse message associated wtdi the response 
code from field 45. 117E is stored in field 264G. The software severity code from label- 
value pair 45. 1 17F is stored in field 264D. The software-message from label-value pair 
45.117G is stored in field 264E. The fee bom label-vahie pair 45.117H is stored in 
15 field 264K, The balance from label-value pair 45.1171 is stored in field 264L. 

Processii^ continues at step 1420 where load/unload process 405 ends. 
E. Open Session Process 407 

Figure 21 depkts a flow diagram ilhistrating open session process 407 
which begins at step 150L 
20 At step 1502, customer applicatira software 210 prompts (requests) 

customer user 203 to enter information relating to the session to be created. This 
information will be included in message OSl sent to server compter 100 and will 
become part of session data structure 130 (Figure 4H). In the preferred embodiment, 
customer user 203 enters the maximum length of time the session will last, the maTiini im 
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number of transactions \^ch may occur during the session and the amount and currency 
of electronic cash available to customer user 203 during the session. Customer user 203 
may also enter an optional description of the session. 

Message OSl will be assembled by and transmitted from customer 
5 computer 200 to server computer 100 to effect open session process 407. The content 
of message OSl is now described with reference to Figures 22A and 22B. 

Label-value pair 4613A has the label *'id*'. The value of label-value pair 
4613A mdicates the persona id for customer user 203. The value of label-value pair 
4613A is obtained from field 220A (Figure SC). 
10 Label-value pair 4613B has the label " transaction". The vahie of label- 

vahie pair 4613B is a transaction number, generated by customs application software 
210, which uniquely identifies message OSl. The value of label-vahie pair 461 3B allows 
server conqniter 100, tqxm receipt of mes^ge OSl, (1) to send an associated reply 
message OS2, described below, and (2) to determine if message OSl is a diq)licate 
15 message (i.e.. ahready received by server computer 100). The vahie associated with 
label-vahie pair 4613B is stored in field 2S6B (FigureSL). 

Label-vahie pair 4613C has the label "date". The value of label-value pair 
4613B indicates the date and time that message OSl was assembled and sent to server 
computer 100, accordkig to the clock of customer computer 200. The value associated 
20 with hbtl'VBtuB pair 4613C is stored in field 256C. 

Label-vahie pair 4613D has the label "serverkey". As described below, 
the DBS key/IV pair used by customer computer 200 to encrypt die opaque label-vahie 
pair 4617 of message OSl is encrypted using an RSA public key of server computer 
100. Label-vahiepair 4613D points the coriespoiiding RSA private key stored in server 
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private key data structure 160. 

Label-valiie pair 4613E has the label "service-category". The value of 
label-value pair 4613E is a label which may be used to route message OSl to a 
processor within server computer 100 that haiKlles messages of a particular service 
5 category. 

Label-value pair 4617 has the label "opaque". The value of label-value 
pair 4617 includes the opaque section contents (in encrypted form) of message OSl . We 
DOW describe the opaque section contents of message 0S1« shown in Figure 22B. 

Label-value pair 4617A has the label "type". The value of label-vahie 
10 pair 4617A references a record in message data structure 150 which sets forth the labels 
of the opaque section contents message OSl. The value of label-value pair 4617A is 
obtained firom cusunner application software 210 which generates the label when 
custon^ user 203 initiates the open session process 407. 

Label- vahie pair 4617B has the label "server-date". The vahie of label- 
15 vahie pair 4617B indicates the date and time message OSl was assembled as measured 
by customer conqiuter 200's perception of server conqniter lOO's clock. 

Label-value pair 4617C has the label "swversion" (software version). The 
value of label-value pair 4617C indicates die version of customer application software 
210 communicating with server computer 100. The value of label-vahie pair 4617C is 
20 obtained from data embedded in customer application software 210. The value 
associated widi label-vahie pair 4617C is stored in field 256D. 

Label-vahie pair 4617D has the label "record-note". The vahie of label- 
value pair 4617D is an optional short text note to be stored in field 130M (Figure 4H). 
For example, the note may state "Christmas Sbqyping" or "ski equipment". The value 
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of label- vahie pair 4617D is obtained from customer user 203 's response to a prompt 
from customer application software 210 and is preferably limited to sixty characters to 
simplify the display produced by customer application software 210. 

Label-value pair 4617E has the label "amoum** and the value entered at 
5 step 1S02 indicating the maximum amount of electronic cash available to customer user 
203 during the session. The value associated with label* value pair 4617E is stored in 
field 256F. 

Label-value pair 4617F has the label "key-lifetime** and the value entered 
at stq> S02 indicating the imximimi length of time the session will last as requested by 
10 customer user 203. The value associated with label-value pair 4617F is stored in field 
256H. 

Label-value pair 4617G has the label ''key-use-limit" and d)e value entered 
at step 1SQ2 indicating the maximum number of transactions which may occur during 
the session as requested by customer user 203. The value associated with label-value 
15 pair 4617G is ^red in field 2S6G. 

Label-value pair 4617H has the label "key" . The value of label-value pair 
4617H represents a hash of the modulus of the RSA public/private key pair of customer 
persona 120.1. The vahie of label-value pair 4617H pemiits server computer 100 to 
confirm that the RSA public key maintained in field 120B (Figure 4B) is the same key 
20 used to sign message OSl Gabel-vahie pair 46171). 

Label-value pair 46171 has the label "signature". The vahie of label-vahie 
pair 46171 represents the digital signature for customer persona 120.1. For message 
OSl, the value of label-vahie pair 46171 is a hash of label-value pairs 4613A'4613D and 
label-vahie pairs 4617A-4617H in alphabetical order, encrypted with the RSA private 
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key for customer persona 120.1. The RSA private key for customer persona 120.1 is 
obtained from field 220H (Figure 5C). 

Message OSl is assembled using message assembly procedure 800 (Figure 
9) described previously for the assembly of registration message Rl. The following 
5 modification is noted for message OSl: A copy of message OS I is preferably saved in 
field 2561. 

In the case of assembly of message OSl by merchant computer 300, a 
new record 370.1 (Figure 7Q is created as follows: 

The value of label-vahie pair 4613B is stored in field 370P. The value 
10 of label-value pair 4617F is stored in field 370Q. Tte value of label-value pair 461 7G 
is stored in field 370R. The value of status field 370O is set to "attmpt" by merchant 
application software 310. 

Referring again to Figure 21, open session process 407 continues at step 
1S04. There, customer computer 200 transmits message OSl to server C(Hnputer 100. 
15 Customer computer 200 waits for a reply message 0S2 from server computer 100. 

At step 1505, server computer 100 receives message OSl from customer 
coootputer 200 and unwraps message OSl by executing server message unwrap procedure 
900. Server message unwrap procedure 900 (steps 901-917) was described previously 
for message Rl with reference to Figure 11. The following modification is noted: A 
20 copy of message OSl is stored m field 140E (Figure 4L). 

At Step 1506, if any of die tests of steps 909A, 912, 914, 915 or 916 
caused an error flag to be set at step 905, error processing procedures are executed by 
server comiwter 100 at step 1514. While the level of error processing at step 1514 is 
Uirgely an administrative decision, it is preferred diat a minimum, failures of the 
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checksum, signature, and fonn, and a "fatal" return on the software check procedure 
result in a return message containing a code that can be processed by customer 
application software 210 and a message that can be read by customer user 203. The 
error processing procedure in step 1514 entails associating a flag with a specific enor 
code (described in the context of the return message 0S2 below) and creating a text 
message (either fix}m a data structure of messages or a message sent by the system 
administrator). Server conq}uter 100 then generates a message 0S2 similar to that 
described below to customer computer 200 conveying the error code and any related 
message. 

If the tests of steps 909A, 912, 914, 913 and 916 did not cause an error 
flag to be set at step 90S, processing continues at step 1507. There, server computer 
100 calculates (computes) a session identification number ("session id"), a session 
encryption/decryption key ("session laej") and a session salt and validates the session 
limits requested by customer user 203 as reflected in message OSl. 

The session id is a 64-bit quantity that uniquely identifies the session being 
created. Uniqueness is ensured because the session ids are sequentially generated by 
server comiHiter 100. 

The session-key is a 12S-bxt quantity containing a 56 bit DES key (64-bits 
with the least significant bit of each eight bit byte ignored) and a 64-bit initialization 
vector. 

The session-salt is an 8-byte cryptographic salt used to strengthen the 
authentication of messages CA1-CA4 which are exchanged during a session. Messages 
CA1-CA4 are described later. 

The session limits requested by customer user 203 are the amount value 
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of Ubel-value pair 4617E. the key-lifetiine value of label-value pair 4617F, and the key- 
uselimit value of label-value pair 4617G. With respect to the key-lifetime and key- 
uselimit. it is preferred that these vahies be subject to a fixed range established by server 
computer 100 to improve system efficiency and maximize the security of transactions 
5 perfonned during a session. Server computerlOO verifies that the requested values are 
within any such lunits. Any requested limit tiiat exceeds a permitted value are ignoi«l 
and the maximum permitted vahie imposed by server computer 100. 

The value of label-value pair 4617E represents the amount of electronic 
fiuKls that custotner user 203 desires to spend during the session. TTie actual amowit of 
10 a«*fiinds made available to customer user 203 during a session may be less d^ 
equal to the amount requested by customer user 203 at step 1502. For example, 
customer user may request more electronic cash than Is available in cash container field 
120G.2 for customer user 203. In diis case, the amount granted, as indicated by Ubel- 
vahie pair 47171 described below, is limited to the amoum stored in cash container field 
15 I20G.2 for customer user 203. 

At step 1508. server session data structure 130 (Figure 4H) is updated, 
nie session id is stored in die session id field 130A. The session key is stored in the 
session key fieM130B. The session salt is stored in the session salt fieklI30C. Tbt 
amountof electronic cash made available to customer user 203 during the session is 
20 stored in openiog amount field 130E and the currency designator associated widi the 
vahie stored in field 130E is stored in field 130D. Initially, field 130F reflects die vahie 
offlie opening amount in field 130E. As electronic cash is spent, die value in field 130F 
leflects the dififerenoe between die opening amount and die amount spent The key- 
lifetime acmaUy granted by server computer 100 is stored in key-lifetime field 130J. 
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The key-uselimit actuaUy granted by server computer 100 is stored in key-use-iimit field 
1301. The value of label-value pair 4613A is stored in persona id field 130K. The date 
that the session was created is obtained ftom server appUcation software 1 10 and stored 
in opening date field 130G. The value of label-pair 4617D is saved in the record note 
field 130M. The remaining fields of server session data structure 130 arc discussed in 
the context of the CA-type messages below. 

After step 1509. message 0S2 is assembled by and transmitted ftom 
server computer 100 to customer computer 200 to complete credit session process 407. 
The contents of message 0S2 is now described with rcfieiencc to Figures 23A and 23B. 

Ubel-value pair 4713A has the label "id". The value of label-vahie pair 
47DA indicates the persona id for customer user 203. The value of label-vahie pair 
4713A is the same as that received in message OSl in label-vahie pair 4613A. 

Label-vahie pair 4713B has the label " transaction". The vahie of label- 
vahie pair 4713B is a transaction number. The vahie of label-vahie pair 4713B is the 
same as that received in message OSl in label-vahie pair 4613B. 

Label-vahie pair 4713C has the label "date". The vahie of label-value pair 
4713C is the same as that received in message OSl in label-vahie pair 4613C. 

Label-value pair 4713D has the label "service-category-. The vahie of 
labcl-vahie pair 4713D is the same as that received in label-value pair 4613E of message 
OSl. 

Labd-vahie pair 4717 has the label "opaque". The vahie of Uibel-vahie 
pair 4717 includes the opaque section contents (in encrypted form) of message 0S2. We 
now describe the opaque section contents of message OS2. shown in Figure 23B. 

Label-vahie pair 4717A has the label "type". The value of label-vahie 
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pair 4717A references a record in message data structure 270 (Figure 5A) which sets 
forth the labels of the opaque section content of message OS2. The value of labei-vaiue 
pair 4717A is obtained from server software 110. 

Label- value pair 4717B has the label "server-date". The value of label- 
5 value pair 4717B indicates the date and time message 0S2 was assembled according to 
the clock of server computer 100, 

Label-value pair 4717C has the label "response-code" and the value 
"success" or "failure" as previously described. Label-value pair 4717C indicates 
whether open session process 407 was a success or failure. 

1 0 Label-vahie pair 4717D has the label "swseverity " (software severity) and 

the vahie "fatal" or "warning". Tbe value of label- vatee pair 4717D indicates whether 
customer application software 210 needs to be updated, but is still usable ("warning") 
or is no longer usable ("fatal"). The vahie of label-vahie pair 4717D is null if customer 
application software 210 is current 

15 Label-vahie pair 4717E has ibc label "swmessage" (software message). 

The label-value pair 4717E indicates instructions as to what customer user 203 should 
do in the case of a "fatal" or "warning" software severity. The value of label-vahie pair 
4717E is only present if the value of label-value pair 4717D is not null. 

Label- value pair 4717F has the label "message". The vahie of label-value 

20 pair 4717F is a free text message associated with an error or success condition returned 
in label-vahie pair 4717C and displayed to customer user 203. The value of label-vahie 
pair 4317F may inchide a message indicating a diq)licaie requested persona id, a bad 
digital signature or an ill formed message OSl and instructions as to how customer user 
203 should proceed (e.g., "call system administrator"). 
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Label-value pair 4717G has the label "key-lifetime" and the value obtained 
from the key-lifetime of field 13QI (Figure 4L) indicating the fnaYimiiTn length of time 
the session will last. 

Labcl-vahie pair 4717H has the label "key-use-limit" and the value 
5 obtained from the key-use-limit of field 1301 indicating the maTim iiTT> number of 
transactions which may occur during the session. 

Label-value pair 47171 has the label "amount" and indicates the 
amount of electronic cash available to customer user 203 during the session. The 
amount vahie of label-value pair 47171 may be less than or equal to the amount 
10 requested by customer user 203 at step 1502. 

Label-value pair 4717J has tte label "foreign-exchange" and a vahie 
indicating a conversion rate from the currency denomination included in the value of 
label-value pair 42171 into other currencies, for example, U.S. dollars into Canadian 
dollars. Preferably, the indicated conversion rate is in the number of minor units (or 
15 major units if there is no minor unit) of the destination currency for hundred major units 
of source currency. 

Label-vahie pair 4717K has the label "session-funds" . The vahie of label- 
value pair 4717K indicafrs an amount of electronic cash sent to all open sessions 
including the amount value of label-value pair 44171. A customs: persona 120. 1 may 
20 have any number of sessions open. Label-value pair 4717K provides customer user 203 
information regarding the anxxmt of funds initially allocated to all open sessions, 
including the session just opened. 

Label-vahxe pair 4717L has die label "balance". The value of label-value 
pair 4717L indicates the amount of electronic cash stored in cash container field 120G.2 
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of server persona data structure 120 for customer user 203 after the transfer of electronic 
cash fimds to opening amount field 130E of server session data structure 130. 

Label-value pair 4717M has the label "on-hold" . The value of label-value 
pair 4717M is obtained from cash container field 120G.3 and indicates the amount of 
5 uncollected electronic cash still being cleared in persona 120. 1 for customer user 203. 
This value represents electronic cash which are awaiting approval or processing by the 
issuer of the instrument from which funds are being load or to which fends are being 
unloaded. 

Label-value pair 4717N has the label "fee" , The value of label-vahie pair 
10 4717N indicates a fiee charged to customer user 203, if any, associated with processing 
message OSL 

Label-vahie pair 47170 has the label "session-id". The vahie of labei- 
vahie pair 47170 is obtained from the session id of field 130A. 

Label-vahie pair 4717P has the label "session-key". Tte vahic of label- 
15 vahie pair 4717P is obtained firom Ae session key of field 130B. 

Label-vahie pair 4717Q has the label "session-salt". The value of label- 
value pair 47I7Q is obtained from the session salt of field I30C. 

At step 1509 of Figure 21, server software 100 assembles message 0S2 
according to the flow diagram of Figure 12. Server message assembly procedure 1000 
20 was described previously for the assembly of message R2. 

At step 1S09A, message OS2 is sent (transmitted) from server computer 
100 to customer computer 200. 

At step 1510, customer con^mter 200 receives message OS2 from server 
computer 100 and unwraps message 0S2 by executing message unwrap procedure 1100 
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for message 0S2. Message unwrap procedure 1100 (steps 1101-1121) was previously 
described for message R2 with reference to Figure 14. 
At step 1511. 

(1) if an error flag was set at step 1105, the flag will be detected at 
step 1511 and processing of message 0S2 terminates at step 1512. From the perspective 
of customer user 203. no further action is taken with respect to message OS2. In the 
present invention, a mechanism is provided within customer application software 210 to 
create and send to server computer 100 a message. This message includes the OS2 
message as received by customer computer 200 and any diagnosis of what caused the 
message to fail. No response to this message is sent by server conqniter 100 to 
customer computer 200. Rather, (b& information is used to ascertain whether a problem 
exists within the system and if qypropriate corrective measures need to be taten, 

(2) if no error flag was set at step 1105 but an error in message OSl 
was detected at step 905, processmg continues at step 1513 where the content of label- 
vatae 4717C is checked. If the vahie of label-value 4717C is other than "success", error 
processing routines are performed at step 1515 fa»igiffg customer application software 
210 to display the message contained in label-value 4717F associated with the contem 
of label-vahie 4717C and to interpret the value of label-value 4717C and take whatever 
action may be associated with that vahie; or 

(3) if message OSl passed the check at step 905 and no flags were set 
at step llOS, processing continues at stq> 1516 where customer application software 210 
qxiates customer database 202. 

Customer session data structure 240 is updated as follows: 
The session id is stored in the session id field 240A. The session key is stored in die 
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session key field 240B. The session salt is stored in tte session salt field 240C. The 
value of label-value pair 47171 includes a currency designator and a quantity. The 
quantity vahie is stored in opening amount field 130E and the currency designator 
associated with the vahie stored in field 130E is stored in field 130D, The value of 
5 label-value pair 4717G is stored in key-lifetime field 240K. The value of label-value 
pair 4717G is stored in key-use-limit field 240J. 

It is noted that field 240F initially will reflect the value of the opening 
amount in field 240E. As electronic cash is spent, the vahie in field 240F will reflect 
the difference between the opening amount aiKl the amount spent. The remaining fields 
10 of customer session data structure 240 are discussed in the context of the CA-type 
messages below. 

In addition to the values recorded in customer session data structure 240, 
record 265 of customer log data structure 260 is updated as follows: The persona id 
from label-value pair 4713A is stored in field 265H. The transaction number from label- 

1 5 value pair 4713B is stored in field 265B. The date from label-value pair 4717B is stored 
in field 265C. The response-code fiom label-value pair 4717C is stored in field 265F. 
The software severity code from label-vahie pair 4717D is stored in field 265D. The 
software-message ftom label-vahie pair 4717E is stored in field 265E* The response 
message associated with the response code from field 4717F is stored in field 265G. 

20 The key-lifetintt frcm label-value pair 4717G is stored in field 265K. The key-use limit 
from label-vahic pair 4717H is store in field 265J. The amount from label-value pair 
47171 is stored in filed 2651. The balance from label-vahie pair 4717L is stored in field 
265P. The fee from label-vahie pair 4717N is stored in field 2650. The session-id 
from label-vahie pair 47170 is stored in field 265L, 
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If the open session process is initiated by mercbant user 303, record 370. 1 
of merchant cash log data structure 370 is iqxlated as follows: 

The response code from label- value pair 4717C is stored in field 370O. 
The message from label-value pair 4717F associated with the response code from label- 
value pair 4717C is saved in field 370T. The session-id from label-value pair 47170 
is stored in field 370S. 

Processing continues at step 1517 where open session process 407 ends. 

F. Tranyirri an/Pavment Process 409 

When customer user 203 and merchant user 303 have open sessions, 
secure cash transactions can occur over the Internet SO. Security in this context means 
that customer user 203 and merchant user 303 can each be confident that its electronic 
funds are not at risk of being accessed by an unauthorized third party and that no 
electronic cash wiU be transferred until both parties have assented to a transaction which 
has been validated by server computer 100. 

A transaction includes a customer user 203 shopping anK)ng Internet SO 
merchant users 303 who have merchant personas 120.2. Usmg weU iooown techniques, 
customer user 203 and a merchant user 303 agree on a price that customer user 203 is 
willing to pay for a product to be provided by merchant user 303. When merchant user 
303 requests paynoent, customer user 203 elects to pay with electronic cash. This 
election drives an exchange of messages resulting in the ultimate payment to merchant 
user 303 for die product purchased by customer user 203. 

Figures 24 A-24C is a flow diagram depicting transaction/ payment process 
409 which begins at step 1701. 

At step 17Q2Anietchant computer 300 assembles message PRl. Message 
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PRl preferably does not include encrypted data. Thus, only steps 814-817 of message 
assembly procedure 800 (Figure 9) are needed to assemble message PRl. The content 
of message PRl is now described with reference to Figure 25. 

Label-value pair 5013A has the label "type". The value of label-vahie 
5 pair 5013A references a record in message data strucniie 270 (Figure 5A) which sets 
forth labels comprising PRl. The vahie of label-value pair 5013A is obtained from 
merchant application software 310. 

Label-value pair 5013B has die label "merchant-id". The value of label- 
vatae pair 5013B indicates the persona id for mercham user 303. The value of label- 
10 value pair 5013B is obtained from field 320A (Figure 6Q. 

Label-value pair 5013C has die label "merchant-order-id". The value of 
label-valiK pair 5013C indicates an order identification immber ("order id") generated 
by merchant computer 300 to identify a particular order. The vahie of label-value pair 
5013C is stored in field 370C (Figure 7C). 

Label-value pair 5013D has die label "merchant-date". The value of 
label-vahie pair 5013D indicates die date and time message PRl was assembled 
according to die dock of merchant conqmter 300. 

Label-value pair 5013E has die label "merchant-swversion" (mercham 
software version). The vahie of label-vahie pair 5013E uidicates die version of mercham 
20 ai^lication software 310 communicating wifli customw computer 200. The vahie of 
label-vahie pair 5013E is obtained from merchant ^Ucation software 310. 

Label-vahie pair 5013F has die label "note". The vahie of label-vahie pair 
5013F describes die pnxluct being provided by merchant user 303 to customer user 203. 
Hie vahie of label-vahie pair 5013F is obtained by merchant application software 310 
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from software provided by merchant 303 or a third-paity. 

Label-value pair 5013G has the label '*meichant*amount". The value of 
label-value pair 5013G describes the currency and the price for the product described in 
label-value pair 5013F. 
5 Label-value pair 5013H has the label "accepts" . The value of label-value 

pair 5013H identifies credit cards accepted by merchant user 303 (if any). The values 
of label-value pair S013H are obtained from merchant user 303. 

Label-value pair 50131 has the label "uri-pay-to*. The value of label- 
value pair S013I is an Internet 50 uniform resource locator. The Internet 50 unifonn 
10 resource locator of label-vahie pair 50131 is the address on the Internet 50 to which 
customer conq>uter 200 is to sends message CAl, described later. 

Label-value pair 5013J has the label 'url-cancelV The vahie of label- 
vahie pair 5013J is an Internet 50 unifonn resource locator. The Internet 50 unifonn 
resource locator of label-value pair 5013J is used by customer computer 200 should 
15 customer \iser 203 decide to cancel a transaction. 

Label-vahie pair 5013K has the label "url-success*. The vahie of label- 
vahie pair 5013K is an Internet 50 uniform resource locator which directs customer 
computer 200 to an address on die world wide web if a traosaction is successful. The 
success of a transaction is reported in message CA4, described later. For example, if 
20 the transaction is validated by server computer 100, the value of label-value pair 5013K 
may direct customer computer 200 to a web page that congratulates customer user 203 
for his or her purchase. 

Label-vahie pair 5013L has the label "url-failure*. The vahie of label- 
value pair 5013L is an Internet 50 uniform resource locator which directs customer 
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computer 200 to an address on the world wide web if a transaction is unsuccessful. The 
failure of a transaction is reported in message CA4, described later. For example, if the 
transaction is not validated by server computer 100, the value of label-value pair 5013L 
may direct customer computer 200 to a web page which requests customer user 203 to 
5 try his or her purchase again. 

Label-value pair 5013M has the label "merchant-signed-hash-key". The 
vahie of label-value pair S013M represents a hash of the modulus part of the RSA 
public/private key pair used by merchant computer 300 to sign the hash of merchant- 
signed hash label-value pair 5013N described below. The value of label-value pair 
10 S013M permits server computer 100 to confirm that the RSA public key maintained in 
field 120CC (Figure 4E) for merchant persona 120.2 is the same key used to sign 
"merchant-signed-hash" label-vahie pair S013N, or if the decryption of label-value pair 
5013N fails, the reason for such failure. 

Label-vahie pair S013N has the label "merchant-signed-hash". For 
15 message PRl , the vahie of label-vahie pair S013N is a hash of label-vahie pairs 5013 A- 
S013M in that order. This hash is signed, meaning that the hash is hashed again, then 
encrypted with the RSA private key for merchant persona 120.2. The RSA private key 
merchant persona 120.2 is obtained from field 320H (Figure 6C). 

Label-vahie pair S013O has the label "merchant-amount2". The value of 
20 label-vahie pair S013O describes die price in currencies other than that associated with 
the price specified in label-vahie pair S013G. 

Customer user 203 cannot authenticate the signature of label-vahie pair 
5013N because it does not have the public key for merchant persona 120.2. The vahie 
of label-vahie pair 5013N may be stored by customer application software in the event 
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that a dispute arises over the transaction. In such event, server computer 100 can use 
the value of label-value pair 5013N to determine if message PRl was actually sent by 
merchant computer 300. 

Referring again to Figure 24A, step 1702B. a new record 350.1 (Figure 
7A) is added (assembled) as follows: 

The vahie of label-value pair 5013C (relating to the merchant-order-id) 
is stored in order-id field 350A. 

The value of label-value pair S013G (relating to the amount that merchant 
user 303 intends to receive in exchange for products) is stored in amount field 350B. 

Transaction/payment process 409 continues at step 1702C. There, 
merchant computer 300 transmits message PRl to customer conq)uter 200. Merchant 
computer 300 waits for message CAl from customer conqHiter 200. 

At step 1702D, customer computer 200 receives message PRl from 
merchant computer 300 and unwraps message PRl by executing message unwr^ 
procedure 3300. Message unwrap procedure 3300 is now described with reference to 
Figure 26, where it begins at stq> 3301. 

At step 3302, customer plication software 210 extracts the protocol 
(version) number of header 5005 of message PRl. Next, based upon the extracted 
protocol number, message template data structure 270 (Figure 5A) is accessed to 
determine the e;qpected format of message PRL The expected format may include 
message syntax (£^, permitted end-of-line characters) and message coding (e^, ASCII 
or hex). Message PRl is parsed in accordance with the expected format as follows. 

At step 3303, customer computer 200 calculates a checksum using the 
same data used by merchant computer 300. At step 3304A, the checksum calculated at 
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step 3303 is compared to the checksum of trailer 5050 of message PRL If the 
checksums are not equal, message PRl is discarded at step 3304B where message 
unwrap procedure 3300 also terminates. 

If the checksums are equal at step 3304A, processing continues at step 
5 3304C where the message is checked to detenxiine if it is appropriate for message 
unwrap procedure 3300. If a message inchides the label "type" in the transparent part 
of the message and the vahie PRl. it is appropriate. If a message does not have this 
label-value pair, it is not appropriate for a message unwrap procedure 3300 in which 
case processing continues at step 3304D where the message is diverted to another 

10 unwrap procedure, described elsewhere. Message PRl is appropriate; therefore, 
processing continues at step 3304E where the message type is determined by reference 
to the vahie of label-value pair 5013A. In this case, the value of label*vahie pair is 
"payment-request " 

At step 3305 a form check of message PRl is performed. The form check 

15 procedure of stsp 3305 is software version dependent. That is, the expected form of the 
message, and the criteria that determine whether it is acceptable, depend on the message 
and zsxy variations of the message that are valid at a given time. At a minimum, the 
form check procedure will ascertain whether an incoming message contains all the labels 
that are prescribed for that message, ^idiedier diere are vahies for each label that requires 

20 a value, aixl whether the vahies are of the type fe.p. . text, signed numbers), syntax and 
within any specified limhs as required. If there are additional labels, customer computer 
200 will ignore than. If a message cannot be parsed, or if it can be parsed but does not 
meet a fonn criteria, an error flag will be set at step 3306. In this case, message 
unwr^ procedure 3300 ends at step 3309. 
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If message PRl has proper form, processing continues at step 3307. 
There, customer application software 210 adds (updates) a new record 266 as follows: 

The merchant-id value of label-value pair 5013B is stored in field 266A. 
The merchant-order-id value of label-value pair 5013C is stored in field 266B. The 
amount value of label-value pair 5013G is stored in field 266C. The merchant-note 
value of label-value pair 5013F is stored in field 266D. The pay-to-URL value of 50131 
is stored in field 266F. 

Message unwrap procedure 3300 ends at step 3309. 

Referring again to Figure 24, at step 1703 customer computer 200 
displays the offer of merchant user 303 to customer user 203. The vahies of label-value 
pair 5013F and S013G (describing the product being sold to customer user 203 and the 
offer price) are displayed. 

At step 1704A, customer user 203 accepts the offer of merchant user 303. 
It is foreseeable that at this juncture, customer user 203 will also be given a variety of 
payment options (e.g. , credit card or electronic cash). If customer user 203 selects 
credit, other pnxresses will take place which arc not described hereiiL If customer user 
203 ixx l ic a t es a desire to pay for the product with electronic cash, processing continues 
at step 1705. 

At step 1705, customer application software 210 determines whether 
customer user 203 has an open session by searching records 240 (Figure 5E). 

If customer user 203 does not have an open session, processing proceeds 
to step 1706. There, a session is created using open session process 405 as described 
above. 

If customer user 203 has an open session, or after open session process 
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405 has been executed, processing continues at step 1707A. There, customer computer 
200 assembles message CAlas follows. 

Referring to Figure 27. message assembly procedure CA12 is depicted. 
("CAI2" references that diis message assembly procedure is executed to assemble 
messages CAl and CA2.) 

Message assembly procedure CA12 for message CAl begins at step 1621 . 
Message CAl is shown in Figures 28A and 28B. 

At step 1622, customer application software 210 accesses message 
template data strucnire 270 (Figure 5A) to obtain a list of labels, which, when matched 
up widi associated values, make up die transparent label-value pairs 5113A-5113I of 
message CAl. At step 1623, vahies are associated with each label. These label-value 
pairs are now described. 

Label-vahie pair 5113A has the label "type". The value of label-vahie 
pair 5113A references a record in message data sttucmre 150 (Figure 4A) which sets 
forfli the labels comprising message CAl. The value of label-value pair 5113A is 
obtained from customer application software 210. 

Label-vahie pair 5113B has die label "version". The vahie of label-value 
pair 5113B is a code maintained in message data strucnire 270 (Figure 5A) which 
references a record witiun die type record indicated by label-vahie pair 5113A. The 
vahie of hbel-vahie pair 5113B is retrieved by customer application software 210 from 
message data stiucture 270. 

Label-vahie pair 5113C has the label "session-id". The vahie of label- 
value pair 5113C is obtained from die session-id of field 240A (Figure 5E). 

Label-vahie pair 5113D has die label "index". TTie vahie of label-vahie 
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pair 5113D is an integer assigned by customer application software 210 to a transaction 
within a session and tepresenis a use of the session key stored in field 240B. The range 
of values is bounded by 1 and the key-use-limit stored in field 240J. 

Label-value pair 5113E has the label "payee-currency" and the value 
indicated by the currency portion of label-value pair 5013G of message PRl . The value 
of label- value pair 5113E describes the currency in which merchant user 303 intends to 
be paid for the transaction. 

Label-value pair 5113F has the label "note-hash". The vahie of label- 
value pair 5113F is a hash of label-value pair 5013F of message PRl. 

Label-value pair 5 1 13G has the label "payee-id" . The value of label-value 
pair 5113G is the merchant persona id obtained from the vahie of label-value pair 5113B 
of message PRl. 

Label-vahic pair 5113H has the label "order-id". The value of label-value 
pair 5113H is die order id obtained ftom the value of labci-vahie pair 5113C of message 
PRl. 

Label-value pair 51131 has die label "service-category". The value of 
label-value pair 51131 is a label which may be used by merchant computer 300 to route 
message CAl to a processor within merchant computer 300 that handles messages of a 
particular service category. 

At step 1624, customer s^pUcation software 210 generates a 56-bit DES 
key DES-CAl according to CA-DES-key generation process 1600, shown in tte flow 
chart of Figure 29, 

Generation of DES key DES-CAl begins at step 1610. 

At step 1611, customer application software 210 constructs (calculates) 
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a quantity Q, an eight byte quantity. Quantity Q is a concatenation of the values of 
label-value pairs 5113A, 5113B and 5113D of message CAl. It is preferred that the 
resulting DES Key change with each message so as to increase the likelihood that each 
DES key generated by CA-DES-key generation process 1600 will be unique. In the 
5 present invention, the value of session key field 240B and label- value pair 5113D 
("index"), when taken together, will normally be different for every request message 
(that is, message CAl and message CA2) and every response message (that is, message 
CA3 and message CA4). In addition, the value of label-vahxe pair 5113A ("type") will 
differentiate the request from the response, resulting a low probability that any two 
10 messages will be encrypted with the same DES key. Additional variability is obtained 
by using labcl-vahie pair 5113B ("version"). 

In the present invention, the concatenation of the value of label-vahie pairs 
5113A, 5113B and 5113D of message CAl results in a four-byte quantity. To reach the 
desired value of eight-bytes, the resulting concatenation is padded on the left side with 
15 four bytes of zeros. 

At step 1612, a 64-bit initialization vector is obtained. The initialization 
vector is die lower 64-bits of tbt session-key of field 240B (Figure 5E). This 
initialization vector was generated during open session process 407, 

At step 1613, a logical "exchisive or" (XOR) operation is performed on 
20 quantity Q cakulated at step 1611 and the initialization vector obtained at step 1612. 

At stq) 1614, d)e result of the XOR operation at step 1613 (a 64.bit value) 
is encrypted using the 56-bit DES key stored in tb& upper 64-bits of the session-key of 
fieki 240B. The 56-bit DES key was generated during open session process 407. 

At step 1615, the parity bits of the encrypted XOR result of step 1614 are 
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stripped. In this manner, tbe 56-bit DES key DES-CAl is created. 

CA-DES-key generation process 1600 for message CAl ends at step 1617. 

Referring again to Figure 27, message assembly procedure CAl 2 for 
message CAl continues at step 1625. There, die DES key DES-CAl is stored (saved) 
5 in a temporary register. 

At step 1626, customer application software 210 accesses message 
template data structure 270 (Figure 5A) to obtain a list of labels, which, when matched 
up with associated values, make up the opaque section contents of message CAl. 

The opaque section contents of message CAl are shown in Figure 28B 
10 where label-value pair S117A has the label "amount". Tte value of label-value pair 
5117A describes the currency and the amount that customer user 203 intends to pay for 
the product. 

Label-vahie pair 5117B has die label "auth-code* and is created at step 
1628. For message CAl, the value of label-value pair S117B is a hash of the 
15 concatenation of the following: 8-byte salt of field 240C, die values of label-value pairs 
5113A, 5113C-5113H, and 5117A and die 8^)yte salt of field 240C. Prior to hashing, 
all white spac^ embedded in die values of label-value pairs S113A, S113C-S113H, and 
S117A is removed and a vertical bar separator character inserted between each adjacent 
pair of values. 

20 This authentication code is not a digital signamre. While a digital 

signature could be used instead of die autb-code reflected in label-vahie pair S117B, the 
cost of such use in terms of processing time is substantial when compared to processing 
a hash. Giventbesafeguardsprovidedby the use of independent sessions having limited 
duration for customer user 203 and a merchant user 303 , the benefit of enczyption-based 
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noQ-iepudiation is not sufficient to outweigh the cost in processor time. 

At step 1629, label-vahie pair 5117B, created at step 1628, is appended 
to label-value pair 5117A. Label- value pairs 5117A and 5117B are encrypted using 
DES-key DES-CAl stored in the temporary register at step 1625. 
5 At step 1630, the data encrypted at step 1629 is encoded using well known 

techniques. 

Message CAl is assembled at steps 1631-1634. At step 1631, header 
5105 is created using the message template found at customer message template data 
structure 270 (Figure 5A) and the protocol number as embedded in customer application 
10 software 210. 

At stq) 1632, the transparent label-vahie pairs 5113A-5113H are 

appended. 

Atstep 1633, opaque label-value pair 5117 is appended. Label-value pair 
5117 has the label "opaque* signifying that the vahie which follows is eocrypted data. 
15 The value of label-value pair 5117 represents the data which was encoded at step 1630. 

Trailer 5150 is assembled at step 1634. The checlcsum of trailer 5150 is 
calculated as descnbed above with respect to sample message 4000. Trailer 5150 is 
added to the remainder of message CAl. 

The assembly of message CAl is now c(xiq>lete. Message assembly 
20 procedure CA12 fwr message CAl ends at step 1635. 

Referring again to Figure 24, processing continues at step 1707A. There, 
customer computer 200 adds a new record 253 (Figure 51) as follows. 

Customer application software 210 creates a value, preferably, "cash- 
paiyment", and saves it at type field 253 A. 
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Customer application software also creates a transaction number and date 
and stores them in transaction number field 253B and date/time field 253C. 

The software version of the customer application software 210 used to 
create message CAl is obtained from customer application software 210 and saved in 
software version field 253D. 

The persona id for custotner persona 120.1 is obtained from field 220A 
and stored in field 253E. 

The value of label-vahic pair 5013C from message PRl is saved in order 

id field 253F, 

The vahie of label-value pair S013B is saved in merchant id field 253G. 

The vahie associated with label-value pair 51 17A is saved in amount field 
253H and deducted from current vahie field 240F of customer session data structure 240. 

User memo field 2S3I stores an optional note (memo) ftom customer 
describing the transaction. The value of field 2S3I is obtained from customer user 203 
in response to a pron^ from customer s^lication software 210 at the time customer 
user 203 agrees to make payment 

The value of label-value pair 50131 firom message PRl is saved in field 

253J. 

A copy of mess^e CAl is preferably saved in field 253K. 

Referring again to Figure 24A, processing continues at step 1708. There, 
customer computer 200 transmits message CAl to merchant conqmter 300. Customer 
computer 200 waits for a reply message CA4 from merchant computer 300. 

At step 1709, merchant computer 300 receives message CAl from 
customer computer 200 and unwraps message CAl by executing message unwrq) 
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procedure CAl. Message unwrap procedure CAl for message CAl is now described 
with reference to Figure 30 where it begins at step 1641. 

At step 1642, merchant software 310 extracts the protocol number of 
header 5105 of message CAl. Next, based on the extracted protocol number of field 
S 5105C, message data stracmre 380 is accessed to determine the expected format of 
message CAl. The expected format may include message syntax (g^, permitted cnd- 
of-line characters) and message coding fe^, ASCH or hex). Message CAl is parsed 
in accordance widi the expected format as foUows. 

At step 1643, merchant conqjuter 300 calculates a checksum using the 
10 same data used by customer computer 200 at step 1633 of message assembly procedure 
CA12 (Figure 27) for message CAl. At step 1644. die checksum calculated at step 
1643 is compared to the checksum of trailer 5150 of message CAl. If the checksums 
are not equal, message CAl is discarded at step 1644D where CAl message unwrap 
procedure terminates. 

If *e checksums are equal at step 1644, processing continues at step 
1644B where the message is checked to determine if it is appropriate for message 
unwrap procedure CAl. A message is appropriate if it inctades die label "type" in the 
transparent part ofthe message and the value indicating a message CAl. Ifamessage 
does not include that label-vahie pair, it is not appropriate. If a message is 
20 inappropriate, processing continues at step 1644C where die message is diverted to 
anoflier merchant unwrap procedure. Message CAl is appropriate; dierefore processing 
continues at step 1644B where the message lype is determined by reference to label- 
vahie pair 5113A. 

At Step 1645, a fonn check of message CAl is performed. The form 
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check procedure of step 1645 is software version dependent. That is. the expected form 
of the message, and the criteria that determine whether it is acceptable, depend on the 
message and any variations of the message that are valid at a given time as determined 
by reference to message type and version information provided in message CAl and 
5 message data structure 380 as previously described. At a minimum, the form check 
procedure will ascertain whether an incoming message contains all the labels that are 
prescribed for that message, whether there are values for each label that requires a 
value, and whether the vahies are of the type text, sigittd numbers), syntax and 
within any specified Ifanits as required. If a message cannot be parsed, or if it can be 
10 parsed but does not meet a form criteria, an error flag will be set at step 1647. In this 
case, message unwrap procedure CAl ends at step 1648. If message CAl passes the 
form check at step 1645, processing continues at step 1646 where the value of label- 
vahie pair 5117 is saved in a temporary register. Message unwr^ procedure CAl is 
complete at step 1648. 

15 Referring again to Figure 24, processing resumes at step 1710A. If error 

flags were set at step 1647, processing continues at step 1710B where merchant error 
processing procedures are invoked. 

If no flags were set at step 1647, processing continues at step 1711A. 
There, merchant computer 300 assembles message CA2 (Figure 31A) according to 
20 message assembly procedure CA12, shown in Figure 27. Message assembly procedure 
CA12 was previously described for message CAl with the foUowing noted exception: 
DES-key DES-CA2 is generated (rather than DES key DES-CAl) using CA-DES-key 
procedure 1600. The content of message CA2, as shown in Figure 31A, is as foUows: 

Label-value pair 5213A has the label "type*. The value of label-value 
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pair S213A references a record in server message data structure ISO which sets forth the 
labels comprising message CA2. The value of label- value pair S213A is obtained from 
merchant application software 310. 

Label-value pair 5213B has the label "version" and references a record 
5 relating to the type record as described above. The value of label- value pair S213B 
contains information regarding the form and content of label-value pairs S213A, 5213C, 
5213D, and S213E and information to decrypt and parse label-value pairs 5217.1 and 
S217.2. As will be discussed later, additional information regarding the form and 
content of label-vahie pairs S217.1 and 5217.2 is provided in label-value pair 5217. IB. 
10 The value of label-value pair 5213B is retrieved by merchant application software 310 
from message data structure 380 (Figure 6A). 

Label-value pair S213C has th& label "session-id". The vahxe of label- 
value pair 5213C is obtained from the session-id of field 340A (Figure 6E). 

Label-value pair 5213D has the label "index". The vahie of label-value 
15 pair 5213D is an integer assigned by merchant application software 310 to a transaction 
widiin a session and represents a use of the session key stored in field 240B. 

Label-vahie pair 5213E has Ae label "service-category". The value of 
label-value pair 5213E is a label which may be used to route messi^e CA2 to a 
processor within server conqniter 100 that handles messages of a particular service 
20 category. 

Message CA2 inchides merchant-opaque label-vahie pair 5217.1 and 
customer opaque label-value pair 5217.2. Label-value pairs 5217.1 and 5217.2 have the 
labels "merchant opaque" and "cusicbmer-opaqoe', respectively, signifying diat the values 
which foUow are encrypted data. The value of label-value pair 5217.1 represents the 
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data which was base-64 encoded at step 1630. The value of label-value pair 5217.2 is 
the value of label-value pair 5117 (forwarded by customer computer 200 in message 
CAl) and saved in the temporary register at step 1646. 

The opaque section contents of message CA2 are shown in Figure 3 IB 
where label-value pair 5217.1 A has the label "type". The value of label-value pair 
5217. lA references a record in message data structure 150 which sets forth the labels 
of the opaque section contents of message CA2. The value of label-value pair 5217. 1 A 
is obtained from merchant application software 310. 

Label-vahie pair 5217. IB has the label "version" and references a record 
within the type record referenced by label-value pair 5217. lA. As previously discussed, 
label-value pair 5217. IB permits the sender of a message to advise die recipient of the 
message what version of that message was sent and to instruct the recipient how to parse 
and process that version. Label-value pair 5217. IB advises server computer 100 of the 
form and content of the opaque label- value pair 5217.1. The value of label-value pair 
5217. IB is obtained firom merchant s^lication software 310. 

The present invention preferably allows merchant computer 300 to submit 
"n" CAl messages received from one or more customer computers 200 to server 
conqmter 100 in a single message CA2. In the current invention, the variable "n" is an 
integer ranging from 1 through 255. A different range ccnild be established depending 
on system capacity and other factors. Message CA2 is structured such that transparent 
label-vataie pairs 5113A-5113D and 5113F-5113H of a received message CAl are 
included in opaque label-vahie pair 5217.1. For each tnusssage CA2 submitted by 
merchant conqxiter 300 to servier conqniter 100, message CA2 includes label-value pairs 
5217.1C-5217.1I (corre^nding to label-vahie pairs 5113A-5113D and 5113F-5113H) 
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and 5217. IJ. More specifically: 

Label-value pair 5217. IC has the label "type„" and the value of label-value 

pair 5117A. 

Label-value pair 5217. ID has the label "subversioUn" and the value of 
5 label-value pair 5117B. 

Label-value pair 5217. IE has tl» label "paycr-session-id^" and the value 
of label-value pair 5117C. 

Label-value pair 5217. IF has the label "paycr-index„" and the value of 
label-value pair 5 1 17D, 
10 Label-value pair 5217. IG has die label "note-hash^" and die value of 

label-vahie pair 5117F. 

Label-value pair 5217. IH has die label "payee-id," and die vahie of label- 
value pair 51 17G. 

Label-vahie pair 5217. II has die label "order-idn" and die value of label- 
15 value pair 5117H. 

Label-value pair 5217. IJ has die label "merchant-amount^". The value 
of label-vahic pair 5217. IJ is provided by merchant plication software 310 and 
describes tbe currency and the amount that merchant user 303 intends to receive for the 
product 

20 Referring again to Figure 24, processing continues at step 1711B where 

merchant computer 330 updates its local data structures as follows. 

A new record 350.1 is created in merchant amount data structure 350 for 
die "n" CAl messages inchided in message CA2. The order id from label-value pair 
order-id-n is stored in field 350A. The merchant-amount from label-vahie pair 
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merchant-amount-n is stored in field 350B. 

Record 370.1 (Figure 7C) is updated as foUows. 
Status field 370B is set to "attempt" by merchant application software 310. 
Merchant user 303*s session-id from label-value pair 5213C is stored in field 370G. The 
5 merchant user 303*s index from label-value pair 5213D is stored in field 370H. The 
session-id of customer user 203 from label-value pair 5217. IE is stored in field 370D. 
The index of customer user 203 from label-value pair 5217. IF is stored in field 370E. 
The merchant currency is taken from the currency symbol value in label-value pair 
5217.1J and saved in field 3701. The amount merchant expects to be paid is taken from 
10 the amoum value in label-value pair 5217. IK and stored in field 370J. 

Referrii^ again to Figure 24, processing continues at step 1712. Tbere, 
merchant computer 300 transmits niessage CA2 to server computer 100. Merchant 
computer 300 waits for a reply message CA3 from server computer 100. 

At step 1713A, server computer 100 receives message CA2 from 
15 merchant computer 300 and saves a copy of the value of label-value pair 5213D of 
message CA2 in index field 130LL.1 (Figure 4J) and a copy of message CA2 in field 
130LL.2. At step 1713B» server unwnq>s message CA2 by executing server message 
unwrap procedure 1660. Server message unwrap procedure 1660 for message CA2 is 
now described widi refoence to Figures 32A and 32B, where it begins at step 1661. 
20 At step 1662, server software 110 extracts the protocol number from field 

5205C of header 5205 of message CA2. Next, based upon the extracted protocol 
number, message data structure 150 is accessed to determine the expected format of 
message CA2. The expected format may inchide message syntax (e.g. . permitted end- 
bf-line characters) and message codmg (e.g.. ASCII or hex). Message CA2 is parsed 
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in accordance widi the expected format as foUows. 

At step 1663, server computer 100 calculates a checksum using die same 
data used by merchant computer 300 at step 1633 of message assembly procedure CA12 
for message CA2. At step 1664. the checksum calculated at step 1663 is compared to 

5 tI»checksumoftraaer5250ofmessageCA2. Ifthechecksumsarenotequal.m^^^ 
CA2 is discarded at sttp 1664A where server message unwrap procedure 1660 
terminates. 

If the checksums are equal at step 1664. processing continues at step 
1665A where the message is checked to determine if it is appropriate for message 

10 ™^ Pi««duie 1600. A message is appropriate if it includes die 

transpaiem part of the message and die value indicatiiig a message CA2. Ifthemessage 
does not inchide this label-vah« pair, it is not appropriate and processing continues at 
step 1665B where tbe message is diverted to another unwrap procedure described 
elsewhere. Message CA2 is appropriate, dierefore. processing continues at step 1665C. 

IS There, die vahie of merchant-opaque label-vahie pair 5217. 1 is decoded. 

At step 1666. server software 110 independently generates DBS key DES- 
CA2 independently from merchant computer 300. according to CA-DES-key generation 
process 1600. desaibed previously. 

At step 1667. die 56-bit DES key DES-CA2 generated by server computer 
20 100 is stored in a len^orary register. 

Processing contimies at step 1668. There, merchant-opaque label-value 
pair 5217.1 is decrypted using DES key DES-CA2. 

At step 1668A. die success or faihue of die decryption of label-value pair 
5217. lis determined. If the decryption foils for any reason, an error flag is set at step 
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1681 aiKl server message unwrap procedure 1660 terminates at step 1682. 

If the decryption is successful, processing continues at step 1668B. 
There, server computer 100 determines whether merchant user 303 has a valid session 
open. Server computer 100 obtains the session id number of merchant from label-value 
5 pair 5213C. The session id is used to obtain merchant record 130.2 for the session 
identified in label-value pair S213C. The opening date stored in field 130GG is then 
compared with the date as determined by reference to server computer lOO's clock and 
the time that has elapsed since the creation of the session calculated. If the amount of 
time that has el^>sed since the creation of the session exceeds the value in key-lifetime 
10 field 130JJ, the session is mvalid. In addition, if the value in index label-value pair 
S213D exceeds the value of the key-use limit stored in fkld 13011, the session use is 
invalid. If the session is mvalid, a session-closed flag is set at step 1681 and CA2 
unwn^ procedure terminates at step 1682 and payment process 1700 continues at step 
1714. 

15 If the session is valid, at step 1668C, the message type is determined by 

reference to label-value pair 5217. lA. For example, vahie of label-value pair 5217.1A 
for message CA2 may be "cash-collection. ' 

Processing continues at step 1669. Tliere, server comiwter 100 performs 
a check of the form of message CA2. The form check procedure of step 1669 is 

20 software version dependent. That is, the expected form of the message, and the criteria 
that determine whether it is acceptable , depend on the message and any variations of dse 
message that are valid at a given time as determined by reference to message type and 
version data stnicoire 150 as previcHisly described. At a minimum, the form check 
procedure will ascertain whether an incoming message contains all the labels that are 
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prescribed for that message, whether there are vahics for each label that requires a 
vahie. and whether die vataes are of die type (e.g., text, signed numben). syntax and 
widiin any specified limits as required. If a message can be parsed but does not meet 
a form criteria, server computer 100 will set an error flag at step 1681 and renirn an 
5 error code in message CAS (described below). In Uiis case, server message unwnip 
procedure 1660 for message CA2 terminates at step 1682. 

If message CA2 passes the form check at step 1669, processing continues 

at step 1670. 

At step 1670. the a ut hen t i c a t ion code of merchant user 303 rq)resenied 
10 by label-vahK pair 5217.1K is verified (checked) as foUows. Server software 110 
obtains die 8-byte salt of fiekll30CC. Server software 110 dien accesses message data 
sttucture 150 to determine which label-vahie pairs were hashed at step 1627 of message 
assembly procedure CA12 for message CA2 to conspaut ±e vahie of label-value pair 
5217. IK. Server software 110 djen hashes diose same label-vahie pairs. The 8-byte salt 
15 of field 130CC is added as bodia prefix of and a suffix to die label-vahic pairs before 
Uw hash is computed. This hash vahie is compared to die vahie of label-value pair 
5217.1K. If die vahies differ, an appropriate error flag is set at step 1681. In diis case, 

server message unwrap procedure 1660 for message CA2tenninates at step 1682. If die 
values match, processing condiHies at step 1671. 

At step 1671, variable "n" is initialized to one. The vahie of variable "n". 
as described above, represents die n* CAl message inchided in message CA2. 

At step 1672, server software 110 geiKrates DES key DES-CAl. 
according to CA-DES-key generation process 1600. DES key DES-CAl generated by 
server computer 100 if stored in a tenqionuy register. 
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At step 1673, customer-opaque label-value pair S217.2 is decrypted using 
DESkey DES-CAl. 

At step 1674. the success or failure of the decryption of label-value pair 
S217.2 is determined. If the decryption fails for any reason, an error flag is set at step 
5 1678 aiKi processing continues at step 1679. There, it is determined if there are more 
CAl messages to process. If so, processing continues at step 1680. If not, server 
message unwrap procedure 1660 terminates at step 1682. 

If the decryption of label-value pair 5217.2 is successful, processing 
continues at step 167S. 

10 At step 1675, if the merchant 303 has a valid open session, server 

computer lOOdeternaines whethor die custoiner user 203 associated with the nth payme^ 
request included in message CA2 has a valid session open. Server computer 100 obtains 
the session id number of custon^ user 203 from label-value pair 5217. IE. The session 
is sued to obtain customer session record 130. 1 for tte session identified in label-value 

15 pair 5217.1E. The opening date stored in field 130G is then compared with the date as 
determined by reference to server computer 100*s clock and the time that has elapsed 
sii^ die creation of the session calculated. The session is invalid if die amount of time 
that has elapsed since the creation of the session exceeds die value in key-lifetime field 
130J. The transaction is invalid if the vahie in index label-vahie pair 5217. IF exceeds 

20 die vahie of die key-use limit stored in field 1301. If the session is invalid, a sessionr 
closed flag is set at step 1678 and processii^ continues at step 1679. There, it is 
determined wither there are more CAl messages to process. If so, processing 
continues at step 1680. If not, server message unwrap procedure 1660 terminates at step 
1682. 
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At step 1676, the authentication code of customer user 203 represented 
by label-value pair 5U7B of message CAl is verified as follows. Server software 110 
obtains the 8-byte salt of field 130C. Server software 1 10 then accesses message data 
structure 150 to determine which label-vahie pairs were hashed at step 1627 of message 
assembly procedure CA12 for message CAl to compute the value of label-value pair 
51 17B. Server software 1 10 then hashes those same label- value pairs. The 8-byte salt 
of field 130C is added as both a prefix of and a sufRx to the label-value pairs before the 
hash is computed. This hash value is compared to the value of label-value pair 51 17B. 
If the values differ, an ^propriace error flag is set at step 1678 and processing continues 
at step 1679. There, it is determined if diere are more CAl messages to process. If 
not, server message unwrap procedure 1660 terminates at step 1682. If so, processing 
continues at step 1680. If the vahies match at step 1675. processing continues at step 
1676. 

If customer user 203*s session is valid, processing continues at step 1676. 

At step 1677. payment to merchant user 303 is effected. For customer 
user 203. this means deducting the amount reflected in amount label-vahie pair 5217.2A 
(Figure 3 IC) fiom tte current amount of field 130F and choiring transaction data 130N 
of record 130.1. Transaction data 130N is shown in Figure 41 wixm the following data 
is captured: The amount in label-vatae pair 5217.2A is stored in field 130N.1; the 
customer session-id firom label-vatae pair 5217. IE is stored in field 130N.2; the order-id 
fit)m label-vahie pair 5217.11 is stored in field 130N.3; the merchant session-id from 
label-vahie pair 5213C is stored in filed 130N.4; and die customer uidex firom label- 
vahie pair 5217. IF is stored m field 130N.5. 

For merchant user 303, this payment means adding the amount reflected 
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in amount field 5117A to the current amount of field 130FF and capturing transaction 
data 130NN of record 130.2. Transaction data 130NN is shown in Figure 4K where the 
following data is captured: The amount in label-value pair 5217.2A is stored in field 
130NN.1; the customer session-id from label-value pair 5217. IE is stored in field 
5 130NN.2; the order-id from labelvalue pair 5217.11 is stored in field 130NN,3; the 
merchant session-id from label-value pair 5213C is stored in filed 130^fN.4; and the 
merchant index from label-value pair 5213D is stored in field 130NN.S. 

At step 1679, server software 110 determines whetter message CA2 
includes additional messages CAl to be processed. If there are additional CAl messages 

10 to be processed, variable "n" is mcremented at step 1680 and processing continues at 
step 1672 as previously described. If there are no additional CAl messages to process, 
server message unwrap procedure 1660 for message CA2 terminates at step 1682. 

Processing continues at step 1714 of Figure 24. There, if error flags were 
set at step 1681 as a result of the checks of steps 1664, 1668A, 1668B, 1669, or 1670, 

15 processing continues at step 1715. There, the type of error will cause an appropriate 
code to be associated with req>onse-code label-value pair 5317.1C and a message to be 
associated with label-value pair 5317. IE. The level of detail detected by error flags and 
reported in the response-code label-vahie pair is a decision for the system administrator. 
For exan^Ie, a "fiuhne" may be a 'hard failure", that is, a ^ihire of a subset of failures 

20 fDt which resubmission of die message would not result in processing of the message 
(£X.t invalid format or session closed). "Failure' could also encontpass a failure which 
can be cured (a time-out because of a temporary outage of server computer 100). In the 
discussion which follows, the term failure wall be used in its broad context. 

If m> flags were set at step 1681, processing proceeds to step 1716 where 
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server computer 100 determines whether the checks at steps 1674, 1675, and 1676 of 
the payment request messages caused an error flag to be set at step 1678. If the nth 
CAl message caused a flag to be set, at step 1717 the value of label-value pair 5317. IK 
(response-code-n)aiid label- value pair 5317.2A (response code) will be set to faihire; 
and label-value pair 5317. IN (problem-n) and label-value pair 5317.2E (problem) will 
assigned a value of a code associated with the vahie of label-value pair 5317. IK. If the 
operator of server computer 100 deems it desirable, a free fonn message regarding the 
failure can be inchided in label-value pair 5317. IL (remark-n) and label-value pair 
5317.5A (remark). 

At step 1718A, server computer 100 assraibles message CAS according 
to server message assembly procedure 34<X), shown in Figure 33. 

Server message assembly procedure 3400 for message CA3 begins at ^ 

3401. 

At step 3402A, server software 110 accesses message type and version 
data structure 150 to obtain a list of labels, which, when matched up with associated 
values, make up the tran^)arcm label-vahie pairs 5313A-5313E for message CA3, shown 
in Figures 34A and 34B. At step 3402B, vahies are associated with each label as 
follows. 

Label-vahie pair 5313A has the label "type". The value of label-vahie 
pair 5313A references a record in message data structure 380 which sets forth the labels 
of message CA3. The vahie of label-vahie pair 5313A is obtained from server software 
110. 

Label-value pair 5313B has tbt label "version" and references a record 
relating to dse record referenced by label-vahic pair 5313A. As previously discussed. 
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label- value pair 5313B permits the sender of a message to advise the recipient as to the 
version of that message and how to parse and process that version. Because message 
CA3 is in response to message CA2 sent by merchant computer 300, the version of 
message CA3 will be selected by server software 110 to assure that it can be processed 
5 by merchant application software 310. Label- value pair 53 138 advises merchant 
application software 310 of the form and content of the transparent label- value pairs 
5313A, 5313C, 5313D. and 5313E. The value of label-value pair 5313B is obtained 
from merchant application software 310. 

Label-value pair S313C has the label "session-id*. The vahie of label- 
10 value pair 5313C is obtained from the session-id of field 130AA of merchant session 
data structure 130. 

Label-vahie pair S313D has the label "index". The value of label-value 
pair S313D is obtained from the index of field 130LL of merchant session data structure 
130.2. 

15 Label-vahae pair 5313E has the label "service-category". The value of 

label-value pair S313E is a label which may be used by merchant computer 300 to nmte 
message CAB to a processor within merchant computer 300 that handles messages of a 
particular service category. 

At step 34Q2C, server software 1 10 generates 56-bit DES keys DES-CA3- 

20 C-n and DES-CA3-M. DES keys DES-CA3-C-n and DES-CA3-M will be used to 
encrypt data to be received by customer computer 200 and merchant computer 300, 
respectively. DES keys DES-CA3-C and DES-CA3-M are generated according to CA- 
DES-key generation process 1600, previously described. 

Referring again to Figure 33, message assembly procedure CAB continues 
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at step 3402D. There, DES keys DES-CA3-C-n and DES-CA3-M are stored in 
temporary registers. 

At step 3403, server software 110 accesses message template data 
structure 150 to obtain a list of labels, which, when matched up with associated values, 

5 make up the merchant opaque section contents of message C A3 (Figure 34B). Values 
are associated with each label as follows. 

The merchant-opaque section contents of message CA3 are shown m 
Figure 34B where label-vahic pair 5317,1A has the label "subtype". The value of label- 
vahie pair 5317. lA is a label referencing a record in message data structure 380 which 
10 inchides the labels of the merchant-opaque section contents for nwssageC Thevahic 
of label-value pair 53 17.1 A is obtained from server software 110. 

Labcl-vahie pair 5317.1B has the label "subversion". The value of label- 
value pair 5317.1B is a code maintained in message data structure 150 which permits 
processing variations of a message type as are vaUd at a given time, 
^5 Label-vahie pair 5317.1C has the label "response-code" and die vahie 

"success" or "faihne" as previously described. Label-value pair 5317. IC indicates 
whether the transaction presertfed to server conqniter 100 by message CA2 was a 
success, faihire, etc. The vatac of label-vahie pair 5317. IC is obtained at step 1715 
described above from server software 110. 

Label-vatae pair 5317.1D has the label "fee". The vahie of label-vahie pair 
5317.1D indicates a fee charged to merchant user 303, if any, associated widi processing 

message CA2. The vatac of labcl-vahie pair 5317. ID is obtained from server software 
110. 

Label-vahie pair 5317.1E has die label "problem". If the response-code 
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value of label-value pair 5317. IC has other than a "success* vahie, the vahie of label- 
value pair 5317. IE is a code advising merchant user 303 as to the cause for the non- 
success. The value of label-value pair 5317. IE is obtained at step 1715 described above 
from server software 110. 
5 Label-value pair 5317.1F has the label "remark". If the response-code 

value of label-value pair 5317.1C has other than a "success" vahie, the vahie of label- 
value pair 5317. IF is a free form text message providing a detailed e?q)lanation of die 
reason for the non-success. The value of label-value pair 5317. If is obtained at step 
1715 described above from server software 110. 
10 Message CA3 inchides the following label-vahie pairs 53 17. lG-53 17. IP 

for each of the "n* CAl messages sulmiiaed with message CA2: 

Label-value pair 5317. IG has the label "subtypes" and die value of label- 
vahie pair 5217. IC of nwssage CA2. 

Label-value pair 5317.1H has the label "subversion^" and the value of 
15 label-vahie pair 5217.1D of message CA2. 

Label-vahie pair 5317.11 has the label "payer-session-id," and die value 
of label-vahie pair 5217. IE of message CA2. 

Label-vahie pair 5317.1J has die label "payer-incteXa" and die value of 
label-value pair 5217. IF of message CA2. 
20 Label-vahie pair 5317.1K has the label "re^nse-codeo" and the vahie 

"success" or "Mure" as previously described. The value of label-vahie pair 5317. IK 
is obtained at step 1717 described above from server software 110. 

Label-vahie pair 5317.1L has die label "remark^". If the response-code 
vaOue of label- value pair 5317.1K has other than a ^'success" value, the vahie of label- 
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value pair 5317. IL is a free fonn text message providing a detaUed explanation of the 
reason for the non-success. The value of label-value pair 5317. IL is obtained at step 
1717 described above from server software 110. 

Label-value pair 5317. IM has the label •coUected-amount„- and the value 
5 indicating the amount of electronic cash collected by merchant user 303 for the 
transaction (at step 1677 of server message unwrap procedure 1660 for message CA2). 

Label-value pair 5317.1N has the label "problem,". If vahie of label- 
value pair 5317.1K has other than a "success" vahie, the vahie of label-value pair 
5317. IN is a code advising customer user 203 as to die cause for die non-success. The 
10 value of label-vahie pair 5317.1N is obtamed at step 1717 described above from server 
software 110. 

Label-vahie pair 5317.10 has the label "order-id„". The value of label- 
vahie pair 5317. lO is obtained from label-vahie pair 5217.11 of message CA2. 

Label-vahie pair 5317.1P has die label "request-version". The value of 
15 label-value pair 5317. IP represents the version of message CA2 acoially processed by 
server conqmter 100. 

Referring again to Figure 33. at step 3405. an audientication code for the 
merchant-opaque section of message CAS. represented by label-value pair 5317. IQ of 
Figure 34B. is created. Label-vahie pair 5317. IQ has the label "audKode". The value 
20 of label-vahie pair 5317.1Q represents die audientication code of server computer 100. 
For die merchant opaque section of message CA3. die vahie of label-vahie pair 53 17. IQ 
is an MD5 hash of die concatenation of die foUowing: 8-byte salt of field 130CC, label- 
vahie pain 5313A-5313E and 5317.1A-5317.1P, and die 8-byte salt of field 130CC. 
Prior to hashing. aU white space embedded in hibel-vahie pain 5313A-5313E and 
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5317.1A-5317.1P is removed. 

At step 3406, label-value pair 53 17. IQ, created at step 3405. is appended 
to label-value pairs 5317. lA-5317. IP. Label-value pairs 5317. 1A-5317.1Q are encrypted 
using the 56-bit DES key DES-CA3-M. 

At step 3407, data encrypted at step 3406 is encoded using well known 

techniques. 

At step 3408, server software 110 accesses message template data 
structure 150 to obtain a list of labels, which, when matched up with associated values, 
make up the customer-opaque section contents of message C A3. At step 3409, the 
customer opaque section is assembled. Vahies are associated with each label as foUows. 

The customer-<q>aqae section contents of message CA3 are shown in 
Figure 34C where labd-value pair 5317.2A has the label "response-code" and the vahie 
"success" or "feihire". Label-vahie pair 5317.2A indicates whedier the transaction 
presented to server computer 100 by message CA2 was a success, feihire. «c. The 
vahie of label-vahie pair 5317.2A is obtained in step 1717 described above from server 
software 110. 

Label-value pair 5317.2B has tihe label "remark". If the response-code 
vahie of label-vatae pair 5317.2A has other than a "success" value, the vahie of label- 
vahie pair 5317.2B is a free form text message providing a detailed explanation of the 
reason for the non-success. The vahie of label-value pair 5317.2B is obtained at step 
1717 described above from server software 1 10. 

Label-vahie pair 5317.2C has die label "foreign-exchange". The value 
of label-vahie pair 5317.2C provides updated infonnatioa regarding a conversion rate 
frtom the cuiteocy denomination included in the vahie of label-vahie pair 5117A into 
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other cunencies. The vahie of label-value pair 5317.2C is obtained ftx)m server 
software 110. 

Label-value pair 5317.2D has the label "amount" and a vahie indicating 
the amount of funds charged to customer user 203 for the transaction. The value of 
5 label-value pair 5317.2D is obtained from server software 110. 

Label-value pair 5317.2E has the label "problem". If the lesponse-code 
value of label-vahie pair 5317.2A has other than a "success" vahie, the value of label- 
vahie pair 5317.2E is a code advising customer user 203 as to die cause for the nwi- 
success. The value of Ubel-vahie pair 5317.2E is obtained at step 1717 described above 
10 from server software 110. 

Label-vahie pair 5317.2F has the label "order-id". The value of label- 
vahie pair 5317.2F is obtained from label-vahie pair 5217.11 of message CA2. 

Label-vahie pair 5317.2G has the label "request-version". The vahie of 
label-value pair 5317.2G represents die version of message CAl acoially processed by 
15 server computer 100. 

Referring again to Figure 33. at step 3410. an authentication code for the 
customer-opaqae section of message CA3. rq)rcsentBd by label-value pair 5317.2H of 
Figure 34C, is created. Label-vahie pair 5317.2H has the label "auth-code". The value 
of label-vahie pair 5317.2H shown in Figure 34C r e pi ei> em s die authenticadon code of 
20 server covapaxa 100. For die custraner-opaque section of message CA3. die value of 
label-value pair 5317.2H is a hash of a concatenation of the foUowing: 8-byte salt of 
field 130C. die vahies of label-vahiepaiis 5313A-5313D and 5317.2A-5317.2G. and die 
8-bytB salt of field 130C. Prior to hashing. aU white space embedded in die vahies of 
label-value pairs 5313A-5313D and 5317.2A-5317.2G is removed and a vertical bar 
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sq)arator character inserted between each adjacent pair of values. 

At step 3411, label-value pair 5317.2H, created at step 3410, is appended 
to label-value pairs 53 17.2A-53 17.2G. Label-value pairs 53 17.2A-53 17.2H are encrypted 
using DES key DES-CA3-C-n. 
5 At step 3412, data encrypted at step 3411 is encoded using well known 

techniques (preferably base 64). 

Message CA3 is assembled at steps 3413-3417. At step 3413, header 
5305 is created using the message template found at type and version data structure 150 
and the protocol number as embedded in server software 110. 
10 Next at step 3414, transparent label-vahie pairs 5313A-5313D are added 

(iqjpended). Label-value pairs 5213A-5213D were described previously. 

At st^ 3415 and 3416, merchant-opaque label-value pair 5317.1 and 
customer-opaque label-vahie pair 5317.2 are appended. Label-value pairs 5317.1 and 
5317.2 have the labels "merchant-opaque" and "customer-opaque% respectively, 
15 signifying that the values which follow are encrypted data. The value of labei-vahie pair 
5317. 1, rqnrsents die data which was encoded at step 3407. The value of label-value 
pair 5317.2 represents the data ^^licfa was encoded at step 3412 (which will be 
forwarded to customer computer 200 in message CA4). 

Trailer 5350 is assembled at step 3417. The checksum of trailer 5350 is 
20 calculated as described above widi respect to sanq>le message 4000. Trailer 5350 is 
added {spptvded) to the remainder of message CA3. 

Tbeassembly of message CA3 is complete. Message assembly procedure 
3400 for message CA3 ends at stqp 3419. 

At step 1719, merchant computer 300 receives message CA3 from server 
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computer 100 and unwraps message CA3 by executing message unwrap procedure 
CA34, Message unwrap procedure CA34 for message CA3 is now described with 
reference to Figure 35, where it begins at step 2072. 

At step 2072, merchant software 310 extracts the protocol nxmiber from 
5 header 5305 of message CA3 . Next, based upon die extracted protocol number message 
data structure 380 is accessed to determine the expected format of message CA3 The 
expected format may include message syntax (ex., permitted end-of-line characters) and 
message coding (e.g., ASCII or hex). Message CAB is parsed in accordance with the 
expected format as follows. 

10 At step 2073, merchant computer 300 calculates a checksum using the 

same data used by server computer 100 at step 3417 of message assembly procedure 
3400 for message CA3. At step 2074, the checksum calculated at step 2073 is compared 
to tb& checksum of trailer 5350 of message CA3. If die checksums are not equal, 
message CA3 is discarded at step 2074A where message unwrap procedure CA34 

15 terminates. 

If the checksums are equal at step 2074, processing continues at step 
2075A where the message is checked to detennine if it is appropriate for message 
unwrap procedure CA34. A mess^e is ^ropriate if it iKhides the label "type" in the 
transparent part of the message and the value indicating a message CA3 or CA4. If a 
20 message does not inchide this label-value pair, it is inappropriate. Processing of 
in^)propriate message occurs at step 2075B where die message is divwted to another 
unwrap procedure described elsewhere. Message CAS is ^ppxopnaitc; flwefore. 
processing contmues at step 2076 where die value of merchant-opaque label-value pair 
5317.1 is decoded. 
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At step 2077, merchant plication software 310 generates the same DES 
key DES-CA3-M generated by server software 1 10 according to CA-DES-key generation 
process 1600. 

At step 2078, DES key DES<:A3-M is stored in a temporary register. 

At step 2079, DES key DES-CA3-M is used to decrypt the value of 
merchant opaque label-value pair 5317.1. 

A check of message CA3 is then performed at step 2080 as follows. 

At step 2080, the success or failure of the decryption of label-value pair 
5317.1 is determined. If the decryption fEuIs for any reason, an error flag is set at step 
2084 and message unwnq) procedure CA34 terminates at step 2085. 

If the decryption is successful, at step 2080A, the message type is 
determined by reference to label-vahie pair 53 17.1 A. For example, vahie of label-vahie 
pair 5317.LA for message CA3 may be "cash-batcb-receipt." 

Processing continues at step 2081. There, merchant computer 300 
performsacheckoftte form of message CAB. The form check procedure of step 2081 
is software version dependent. That is, the expected form of the message, and the 
criteria that determine whether it is acceptable, ilcpeod on the message and ai^ 
variations of the message that are valid at a given time as determined by reference to 
message type and version information provided in message CAB and message tanphxe 
structure 380 as previously described. At a minimum, die form check procedure will 
ascertain whether an incoming message contains all the labels that are prescribed for that 
message, wh^her diere are values for each labels that requires a vahie, and whether the 
values are of tte type (e.g.. text, signed numbers) , syntax and withm any specified limits 
as required. If a message cannot be parsed, or can be parsed but does not meet a form 
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criteria, merchant computer 300 wiU set an error flag at step 2084 and message unwrap 
procedure CA34 terminates at step 2085. 

If message CA3 passes the form check at step 2081, processing continues 
at step 2082. There, the audientication code represented by label-value pair 5317. ip is 
verified as follows. Merchant software 310 obtains the 8-byte salt of field 340C (Figure 
6E). Based on the value of subtype label-value pair 5317. lA and subversion label-value 
pair 5317. IB, merchant application software 310 accesses message template data 
structure 380 to determine which label-vahie pairs were hashed at step 3405 of message 
assembly procedure CA3 to compute the vahie of label-value pair 5317. IP. Merchant 
application software 310 then adds the 8-byte salt of field 340C as both a prefix of and 
a suffix to the values of those same label-vahie pairs and computes the hash of the result 
This hash value is compared to the value of label-vahie pair 5317. IQ. If the vahies 
differ, an appropriate error flag is set at step 2084. Message unwrap procedure CA34 
terminates at step 2085. 

Referring again to Figure 24, processing continues at step 1720. There, 

(1) if an error flag was set at step 2084, the flag will be detected at 
step 1720 and processing of message CA3 will terminate after step 1721. 

(2) if no error flag was set at step 2084 but an error in message CA2 
was detected at step 1681. processing wifl continue at step 1722 where the coniem of 
label-vahie pair 5317. IC is checked. If the value of label-vahie 5317. IC is other than 
"success", error processing routines are performed at step 1723 causiiig merchant 
^Ucation software 310 to display the message contained m labei-vahie 53 17. IF 
associated with the content of labd-vahie 5317.1C. Merchant application software 310 
WiU also interpret the vahie of label-vahie 5317. IE and lake whatever action may be 
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associated with that value and CA3 message processing eiKis at step 1733; or 

(3) if message CA3 passed the check at step 1720 aiid step 1722, 
processing continues at step 1724 where merchant computer 300 updates local data 
structure as follows. 

5 Record 350. 1 (Figure 7A) is updated to reflect whether a payment request 

was paid. Field 3S0C contains a flag which is set to either "paid" or "not-paid", 
depending on whether the response-code from label-value pair S317.1C is "success" or 
"failure". Similariy, record 370.1 (Figure 7Q is updated to reflea the status of a 
particular payment request. Field 370B, which is set to "attempt" at the time a 

10 particular payment request is sent to server computer 100 in message CA2, is set to 
"success" or "fisulure" depending on whether the response<ode from label-value pair 
5317. IC is "success" or "^ihire". The result code from label-vahie pair 5317. IE is 
stored in field 370M. The fee paid by merchant user 303 for processing of the payment 
request from label-value pair 5317. ID is stored in field 370L. The amount collected by 

15 merchant user 303 for a particular payment request from label-value pair 5317. IM is 
stored in field 370K and is added to field 360F of record 360.1 of sales session data 
structure 360. 

At step 1725, merchant conqniter 300 assembles message CA4 according 
to message assembly procedure 31(X), shown in Figure 36. Message CA4 is shown in 
20 Figures 37A and 37B. 

Message assembly procedure 3100 for message CA4 begins at step 3101. 
At step 3102, header 5405 is created using die message template found at message data 
structure 380 and the protocol numb^ protocol as embedded in merchant application 
software 310. 
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Next, at step 3103, transparent label-value pairs 5413A-5413G are added 

(appended). 

I^bel-value pair 5413A has the label "type". The value of label-value 
pair 5413A references a record in message data structure 270 (Figure 5A) which sets 
5 forth the labels of message CA4. The vahie of label-value pair 5413A is obtained fix>m 
merchant application software 310. 

Label-value pair 5413B has the label "version" and references a record 
relating to the record referenced by label-vahie pair 5413A. As previously discussed, 
label-vahie pair 5413B permits the sender of a message to advise die recipient as to die 
10 version of diat message how to parse and process that version. Because message CA4 
is in response to message CAl from customer user 203, die version used by merchant 
application software 310 to construct message CA4 will be selected by merchant 
appUcation software 310 to assure diat it can be processed by customer application 
software 210. Label-vahie pair 5413B advises customer application software 210 of die 
form and content of bodi die transparent label-vahie pairs 5413A, 5413C and 5413D and 
the opaque label-vahie pair 5417. The vahie of label-value pair 5413B is obtained from 
merchant appUcation software 310. 

Label-vahie pair 5413C has die label "session-id" and a vahie radicating 
die current session id for customer user 203. Merchant computer 300 obtains the value 
of label-vahie pair 5413C from die session-id vahie of label-value pair 5 1 13C of message 
CAl. 

Label-vahie pair 5413D has die label "index". The value of label-value 
pair 5413D is an integer selected from a range of unused vahies indicating each dme 
different transactions widi a session is attempted. Merchant user 303 obtains die vahie 
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of label-value pair 5413D from the index value of label-value pair 5113D of message 
CAl. 

Label- value pair 5413F has the label "order-id". The value of label-value 
pair 5413F indicate?^ the order identification number generated by merchant computer 
5 300 to identify the order. The value of label-value pair 5413F is the same as that 
provided in label-value pair 5013C of message PRl. 

Label-value pair 5413G has the label "service-category". The value of 
label-value pair 5413G is a label which may be used by customer computer 100 to route 
message CA4 to a processor within customer computer 200 that handles messages of a 
10 particular service category. 

At step 3104» opaque labcl-vahie pair 5417 is appended. Label-vahie pair 
5417 has the label "opaque" signifying that the value which follows is encrypted data. 
The vahie of label-vahie pair 5417 represents the vahie of label-vahie pair 5317.2. 
forwarded from server computer 100 to merchant computer 300. 
15 Trailer 5450 is assembled at step 3105. The checksum of trailer 5450 is 

calculated as described above with respect to sample message 4000. Trailer 5450 is 
added (appended) to the remainder of message CA4. 

The assembly of message CA4 is now complete. Message assembly 

procedure 3100 ends at step 3106. 
20 Referring again to Figure 24, processing continues at step 1726. There, 

merdiant conqnzter 300 transmits message CA4 to customer conqniter 200. 

At step 1727, customer computer 200 receives message CA4 from 
merdiant computer 300 and unwraps message C A4 by executii^ mess^e unwr^ 
procedure CA34. Message unwrap procedure CA34 for message CA4 was previously 
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described for message CAS with reference to Figure 35. 

Referring again to Figure 24, processing continues at step 1728. There, 
(1) if an error flag was set at step 2084, die flag will be detected at 

step 1728 and processing of message CA4 will tenninate after step 1729; or 

5 (2) if no error flag was set at step 2084 but an error in message CAl 

was detected at step 1678, processing will continue at step 1730 where die content of 
label-value pair 5417A is checked. If the vahie of label-vahie 5317A is odier dian 
"success", error processing routines arc performed at step 1731 causing customer 
plication software 210 to di^lay die message contained in label-vahie 5417B 
10 associated widi the content of label-vatoe 5317. IC. Customer qiplication software 210 
will also interpret die vahie of label-vahie 5417E and take whatever action may be 
associated widi diat vahie and processing message CA4 will terminate at sttp 1733; or 
(3) if messa^ CA4 passed die check at step 1728 and step 1730, 
processing continues at step 1732 where customer computer 200 updates its data 
15 structures as follows. Customer conqntter 200 conq>ares the value contained in label- 
value pair 5417D widi die vahie of label-value pair 51 17A. If die vahies are different 
customer computer 200 adjusts die current amount field 240D to reflect die amount 

acoiaUy deducted fixHn cunm anwunt fieM 130F as maintained by server conqjuter 100. 
In addition to die vahies recorded m custraner session data structure 240, a new recoid 
50 263 of customer log data strucmrc 260 is created as foUows: The date from label-vahie 
pair 5413E is stared in field 263C. The response^ode ftom labd-vahie pair 5417A is 
stored m fiehl 263D. The remark from label-vahie pair 5417B associated widi die 
response code from tabel-vahie pair 5417A is stored m field 263E. The amount ftom 
label-value pair 5417D is stored m filed 263J. TTie oider-id ftom label-vahie pair 5417F 
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is stored in field 263G. The session-id from label-value pair 5413C is stored in field 
263L. The index firom label- value pair 541 3D is stored in field 263M. 
G. Close Session frocess 411 

Close session process 411 may be used by customer user 203 to close a 

5 session. 

Figure 38 depicts a flow diagram illustrating close session process 411 

whi(± begins at step 1801. 

At step 1802, customer application software 210 prompts (requests) 

customer user 203 to enter the identification number of the session to be closed, any 
10 record-Qote to be attached to a session, and whether customer user 203 desires a log of 

transactions submitted to server computer 100 by merchant 303 for customer user 203 

during the session that is being closed. If customer user 203 has more than one session 

open, the prompt wiU inchide a Ust of all open sessions and request customer user 203 

to select the session to close. 
15 The content of message CS] is now described with reference to Figures 

39A and 39B. 

Label-value pair 4813 A has the label "id". The value of label-value pair 
4813A indicates the persona id for customer user 203. The vahie of label-value pair 
4813A is obtained firom field 220A (Figure 5Q. 
20 Label-vahie pair 4813B has the label "transaction". The vahie of label- 

value pair 48I3B is a transaction number, generated by customer application software 
210, which uniquely identifies mess^e CSl . The vahie of label-value pair 4813B allows 
server computer 100, upon receipt of message CSl, (1) to send an associated reply 
message CS2, described below, and (2) to determine if message CSl is a di^iicate 
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message (Le^., already received by server computer 100). The value associated with 
label-vahie pair 4813B is stored in field 256B. 

Label-value pair 48I3C has the label "date" . The value of label-value pair 
4813C indicates the date and time that message CSl was assembled and sent to server 
computer 100, according to the clock of customer computer 200. The value associated 
with label-value pair 4813C is stored in field 256C. 

Label-value pair 4813D has the label "serverkey". As previously 
described, the DES key/IV pair used by customer counter 200 to encrypt the opaque 
label-vahie pair 4817 of message CSl is cnciyptcd using an RSA public key of server 
computer 100. Label-vahie pair 4813D points to die corresponding RSA private key as 
stored in server private key data structure 160. 

Label-vahie pair 4813E has the label "service-category". The value of 
label-vahie pair 4813E is a label which may be used by server computer 100 to route 
message CSl to a processor within server conq>uter 100 diat handles messages of a 
particular service category. 

Label-vahie pair 4817 is described next Label-vahie pair 4817 has the 
label "opaque" signifying that die vahie which follows is encrypted data. The value of 
label-value pair 4817 represents the data which was erK:oded at step 813. The opaque 
section contents of message CSl (Figure 39B) is as follows: 

Labcl-vahic pair 4817A has the label "type". Label-value pair 4817A 
references a record in message data structure 150 which sets forth the labels of the 
opaxpc secdom contents message CS 1. The vahie of label-value pair 4817A is obtained 
from customer plication software 210 which generates the label when customer user 
203 initiates close session process 411. 
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Label- value pair 4817B has the label "server-date". The vahie of label- 
value pair 48 17B indicates the date and time message CSl was assembled. This date and 
time is customer computer 20O's perception of server computer lOO's clock. 

Label-value pair 4817C has the label "swversion" (software version). The 
5 valxie of label- value pair 4817C indicates the version of customer application software 
210 communicating with server computer 100 and is obtained from data embedded in 
customer application software 210. The value associated with label-vahie pair 4817C 
is also in field 2S6D. 

Label-vahae pair 4817D has die label "record-note*. The value of label- 
10 value pair 4817D is an optional short text note to be stored in field 130M of server 
session data structure 130 relating to the current close session process 411. The value 
of label-value pair 4817D is obtained from customer iiser 203*s response to a prompt 
from customer application software 210 and is preferably limited to sixty characters to 
for convenirace in display. If a record-note was created by customer user 203 during 
15 open session process 407, the value of label-value pair 4817D is added to the value 
previously stored in field 130M. 

Label-value pair 4817E has the label "session-id**. The vahie associated 
with label-vahie pair 4817E is obtained from field 240A of customer session data 
structure 240 and is stored m field 2S5F. 
20 Label-vahie pair 4817F has the label 'request-log". The value associated 

with label-vahie pair 4817F is either "yes" or "no". The value of label-value pair 4817F 
reflects whether customer user 203 has elected to receive a log of the transactions at step 
1802. The vahie of label-vahie pair 4817F is stored m field 2S6G of customer pending 
data structure 250. 
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Label-value pair 4817G has the label "key". The value of label-vahie pair 
4817H represents a hash of the modulus part of the RSA public/private key pair of 
customer peisona 120. 1 . The value of label-value pair 4817G permits server computer 
100 to confirm that the RSA public key maintained in field 120B (Figure 4B) is the same 
5 key used to sign message CSl (label-value pair 4817H). 

Label-value pair 4817H has the label "signature". The value of label- 
value pair 48171 represents the digital signature of customer persona 120. 1 . For message 
CSl. the value of label-vahie pair 4817H is a hash of label-vahie pairs 4813A-4813E and 
label-value pairs 4817A-4817G in alphabetical order, encrypted with the RSA private 
10 key of customer persona 120.1. The RSA private key of customer persona 120.1 is 
(Stained from field 220H. 

At step 1803. message CSl is assembled in accordance with message 
assembly procedure 800. Message assembly procedure 800 was previously described 
for message Rl with reference to Figure 9. One noted exception: A copy of message 
15 CSl is saved in field 256H. 

Reforing again to Figure 38. close session process 411 continues at step 
1804. There, customer con^wter 200 transmits message CSl to server conqmter 100. 
Customer computer 200 waits for a reply message CS2 ftom server conqHiter 100. 

At step 1805, server conqjuter 100 receives message CSl firom customer 
20 computer 200 and unwraps message CSl by executing server message unwnip procedure 
900 for message CSl. Server message unwrap procedure 900 was previously described 
for message Rl with reference to Figure 11. A noted exception: a copy of message CSl 
is stored in field 140E. 

At step ) 806. if any of the tests of steps 904, 909A. 912. 914, 915 or 916 
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caused an error flag to be set at step 90S, error processing procedures are executed by 
server computer 100 at step 1814. While the level of error processing at step 1814 is 
largely an administrative decision, it is preferred that a minimum, failures of the 
signature, and form, and a "fatal** return on the software check procedure result in a 
5 return message containing a code that can be processed by customer application software 
210 and a message that can be read by customer user 203. The error processing 
procedure in step 1814 entails associating a flag with a specific error code (described in 
the context of the return message CS2 below) and creating a text message (either from 
a data structure of messages or a message sent by the system administrator). Server 

1 0 computer 100 then generates a message CS2 sunilar to that described below to customer 
computer 200 conveying the error code and any related message. 

If the tests of steps 904, 909A, 912, 914, 91S and 916 did not cause an 
error flag to be sec at step 90S, processing continues at step 1807. There, server 
conqmter 100 invalidates (u^tes server data structures) the session identified in label- 

15 vahie pair 4817E by setting the status flag in field 130L to "closed". 

At step 1809, server software 110 assembles reply message CS2, 
according to server message assembly procedure 1(X)0. Server message assembly 
procedure 1000 was previcMisly described for message R2, with reference to Figure 12. 
The content of message CS2 (figure 40A and 40B) is now described. 

2 0 Label-vahie pair 4913A has the label "id" . The value of label-vahie pair 

4913A indicates the persona id for customer user 203. The value of label-value pair 
4913A is obtained from the vahie of label-vahie pair 4313A of message CSl. 

Label-value pair 4913B has the label "transaction". The vahse of label- 
value pair 4913B is a transaction number. The value of label-vahie pair 4913B is the 
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same as that received in message CSl in label-value pair 4813B. 

Label-value pair 4913C has the label "date". Label- value pair4913C has 
the same value as label- value pair 4813C of message CSl. 

Label-value pair 4913D has the label "service-category" . Label-value pair 
5 4913D has the same value as label- value pair 4813E of message CSl. 

The opaque section contents of message CS2 are shown in Figure 40B 
where label-value pair 4917A has the label "type". The value of label-value pair 4917A 
references a record in message data structure 270 (Figure S A) which sets forth the labels 
of the opaque section contents of message CS2. The value of label-value pair 4917A is 
10 obtained from server software 110. 

Label-vahie pair 4917B has the label "server-dale". The vahic of label- 
value pair 4917B indicates the date and time message CS2 was assembled according to 
the clock of server computer 100. 

Label-value pair 4917C has the label "response-code". The vahie of label- 
15 value pair 4917C indicates whether close session process 411 was a success or future. 

Label-vahie pair 4917D has the label "swseverity" (software severity). 
The vahie of label-value pair 4917D indicates whether custcHner plication software 210 
needs to be iqxlated, but is still usable ("warning") or is no longer usable ("fatal"). The 
value of label-vahie pair 4917D is null if customer application software 210 is current. 
20 Label-vahie pair 4917E has the label "swmessage" (software message). 

The value of label-vahie pair 4917E indicates instructions as to what customer user 203 
should do in the case of a "fatal" or "warning" software severity. The value of label- 
value pair 4917E is only present if the vahie of label-value pair 4917D is not null. 

Label-value pair 4917F has the label "message". The vahie of label-value 
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pair 4917F is a free text message associated with an error or success condition returned 
in label-value pair 4917C and is displayed to customer user 203. 

Label-value pair 4917G has the label "fee". The value of label-value pair 
4917G indicates a fee, if any» charged to customer user 203 for processing message 
5 CSl. 

Label-value pair 4917H has the label "amount" and indicates the amount 
of electronic funds remaining firom the amoimt allocated to the session during open 
session process 407 after all payments and fees are deducted. If the process of message 
CSl is successful, the amount represented by label-vahie pair 4917H will be added to 
10 cash container field 120G.2 (Figure 4Q. 

The assembly of message CS2 is now complete. 

Referring again to Figure 38, at step 1809A, message CS2 is sent 
(transmitted) from server conqniter 100 to customer computer 200. 

At step 1810, customer computer 200 receives message CS2 from server 
15 computer 100 and unwraps message CS2 by executing message unwrap procedure 1 100. 
Message unwrap procedure 1 100 for message CS2 was previously described for message 
R2 with reference to Figure 14. 

At step 1811, 

(1) if an error flag was set at step 1105, the flag will be detected at 
20 step 1811 and processing of message CS2 will temunate at step 1812. From the 
perspective of customer user 203, no further action is taken with respect to message 
CS2. In the present invendon, a ingghanigm is provided widiin customer application 
software 210 to create and send to server computer 100 a message. This message 
includes the CS2 message as received by customer computer 200 and any diagnosis of 
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what caused the message to fail. No response to this message is sent by server computer 
100 to customer computer 200. Rather, the information is used to ascertain whether a 
problem exists within the system and if appropriate corrective measures need to be 
taken. 

(2) if no error flag was set at step 1 105 but an error in message CSl 
was detected at step 905, processing will continue at step 1813 wtere the content of 
label-value pair 4717C is checked. If the value of label-value pair 4917C is other than 
"success", error processing routines are performed at step 1815 causing customer 
appUcation software 210 to display the message contained in label-vahie pair 4917F 
associated with the content of label-value pair 4917C and to interpret the value of label- 
vahie pair 4917C and take whatever action may be associated wifli that vahie; or 

(3) if message CSl passed the check at step 90S and no flags were set 
at step 1105, processing contmucs at step 1816 where customer a^jplication software 210 
updates customer data strucmre 202 as follows: 

The amount from label-vahie pair 4917H is added to ffeW 2201. 

Record 267 of customer log data strucmre 260 is updated as follows: the 
persona id from label-value pair 4913A is stored in field 267H. Tte transaction number 
from label-vahie pair 4913B is stored in field 267B, The date from label-vatae pair 
4917B is stored in field 267C. The response-code from label-vahie pair 4917C is stored 
in field 267F. The software severity code from label-value pair 4917D is stored in field 
267D. The software-message from label-vatae pair 4917E is stored in field 267E. The 
response message associated with the response code from label-vahie pair 4917F is 
stored in field 267G. The fee frpm label-vatae pair 4917G is stored in field 267K. The 
amount from label-vatae pair 4917H is stored in field 2671. 
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If the value of request-log label-value pair 4817F in message CSl was set 
to "yes", a report will be delivered to customer computer 200 of all transactioDS initiated 
by customer user 203 during the session just closed. 

Processing continues at step 1817 where close session process 411 ends. 
5 v. Sample Transaction 

Below is a description of a sample transaction. In the sample transaction, 
customer user 203 and merchant user 303 each perform registration process 401, 
instrument binding process 403, load/unload process 405, open session process 407, 
transaction payment process 409, and close session process 411. By performing these 
10 processes, customer user 203 is able to purchase a pair of "rocket shoes** fix)m Acme 
Products. 

It should be noted that in the current invention, message label-value pairs 
for which no value have been assigned are preferably not included in a transmitted 
message. This attribute of die current invention is reflected in the sample messages 
15 depicted below. 

A. Re gistration Process 401 

Registration process 401 is identical for a customer and a merchant. Only 
the registration of customer user 203 is described below. 

Customer user 203 runs customer application software 210 which pronq>ts 
20 customer iiser 203 for its assent to one or more legal agreements. In response to a 
request for customer user 203's assent to a legal agreement, customer user 203 selects 
"agreed". Customer application software 210 then prompts customer user 203 for the 
following information: a desired persona id, the email address of customer user 203, the 
desired language in which any error messages will be displayed, the autoclose passphrase 
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to be associated with the persona, and the defeult cunency of the persona. 

In response to a prompt for a desired persona id, customer user 203 
selects -brianb". In response to a prompt for an tbt email address, customer user 203 
enters "brianbOreaUty.com-. In response to a prompt for die desired language for error 
S messages, customer user 203 selects -English". In response to a prompt for the 
autoclose passphrase associated with die persona, customer user 203 enters "badnews". 
In response to a prompt for the defeult currency of the persona, customer selects "U.S. 
doUars'. 

Customer user 203 is prompted to enter a password. Customer user 203 
10 dien emers "emerprise-. Customer user 203 is prompted to re-enter die password and 
complies. Customer application software 210 dien generates a RSA public/private key 
pair and initiates the creation of message Rl as previously described, which message 
mill include die following: 

transaction-number 2277052 

f**- . 19951105100505456 
serverkey: cClOOl 

registration 

senoceH^tegory: jujmin 
opaque: 

0 server-date: 19951105100506656 

swversion: i.Owin 

coniHit-language: en-us 

default-cuncncy: usd 

requested-id: BtianB 

^ brianb@reaHty.com 
agreements: 75 

antoclose-pas^Arase: badnews 

P^^' aslfflasdflasjyuajslyaflggslakjfyldskajyfllcajsyl 
J dQlaskfaslQflasdflasjylg^slalg^yresdliakpoiuq 

wasderfgtbyujikolpknm75cxzI 

^jflsajflksjdlkgisalgflWsajflksjgslalgfydslcy^ 
Qslalgfyldskajydjlfisdlqjiytuazxcnmklokmnuh 
bvgyckdxszaqwe3i5t6y7u8ioI09km+ 

Server computer 100 creates a new record 140.1 in server message log 
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140 and saves a copy of message Rl in field 140E. Server computer 100 then 

unwraps message Rl and processes it as previously described and updates record 

140.1 of server message log 140 as follows: 

persona-id: brianb-23 
se$sion*id 

transaction-number: 2277052 
index: 

incoming-message: copy of message Rl 
response-message: 

Server con^)uter 100 then compares the id requested by customer user 

203 to the list of existing personas. If the requested persona id is unique, it creates a 

persona record 120.1 for customer user 203 as follows: 

persona-id: brianb-23 
15 email: brianb@rcality.com 

pubUckey: asl^flasdflasjyifdjslyaflgeslalgfyldskajyfll^^ 

flasjykjgsla^guyrcsdfirtkpoiuqwasdcrfgthyujito^ 

date-registered: 19951 105100507556 

content-language: en-us 

20 autoclose-passphrase: badnews 
cash-container-data: 
agreements: 

instrument-binding-data: 

25 Server computer 100 then assembles message R2. saves a copy of it in 

field 140F of record 140,1 of server message log data stiucttare 140, and transmits 
message R2 to customer computer 200. Message R2 contains the foUowing: 

transaction: 2277052 
date: 19951105100505456 
30 type: registration-response 
service-category: admin 
opaque: 

server-dale: 19951105100507556 
tequested-id: brianb 
3 5 reqxmse-id: brianb-23 

enuul: brianb@reality.com 
response-code: success 

pubkey: aslflflasdflasjylfdjslyaflgflslalgfyldskajyflta^ 
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aslrfaslQflasdflasjykjfjsIakjQuyresdfutkpoi^ 

rfgthyujikolpkmn75cxzl 
swscverity: warning 
swmessage; New software is available. 

Customer computer 200 unwraps and processes message R2 as 

previously described. Customer application software 210 creates a recotxl of persona 

"brianb-23* in customer persona data structure 220 as follows: 

persona-id: brianb-23 

email: brianb@reality ! com 

public-key: 

aslfiflasdflasjylfdjslyaflcjQslakjfyldskajy^^ 

jflasdflasjylg^slakjQuyiWdfiitkpoi^ 

mnTScxzl 

date-registered: 19951 105100507556 

content-language: en-us 
autoclose-passphrase: badnews 
casb<ontainer-data: 
agreements: 75 
instrument-binding data: 
software-options: default 
private-key: 

8ikuhbrfvedc3erfg56yu87yg0oknisdfghjlc3erfqwerty7yuM 
ij7yfgdcsdfv6y89i0oohijinlmcvzx2wdpIkjhgffdsawe/9 +45 
rf6tg7yblghg£2waaz4ed5tgfv 

B. fastomait Bindm2 Ptoccss 4Ca 

Instrument binding process 403 is the same for bocfa customers and 
merchants. Only the binding of an instrument by customer user 203 will be 
described. 

Bind iistrument process 403 begins when customer user 203 selects the 
bind instrument operation ftom the client aH)lication, Customer appUcation software 
210 pron^ customer user 203 for a default name and address. Customer user 203 
then enters "Brian Brian, 100 Ehn Street, Nice Place, VA 00000 USAV 

Customer user 203 selects "bank account" and is prxHx^>ted for the 
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following infonnation: bank account number; whether the bank account is the 
autoclose account for the persona; a description of the account; and customer user 
203 's assent to one more legal agreement. Customer user is prompted to change any 
information necessary to describe the name, address, and telephone number of the 
5 holder of the instrument. 

In response to a prompt for a the bank account number, customer user 
203 enter "059013218175654". In response to a prompt to the response for whether 
the accoimt is the autoclose account for the persona, customer user 203 enters "yes". 
In response to a prompt to change the displayed name, address, and telephone 

10 number, customer user 203 declines. 

In response to a prompt for a description of the account, customer user 
203 enters "My fun account". In response to a prompt for customer user 203's 
assent to a legal agreement, customer selects "agreed". Customer user 203 is 
prompted to "bind instrament" with server computer 100. This act causes customer 

15 {plication software 210 to create a message BIl as previously described, which 
message will include the following: 



transaction-number 
date: 
20 serverkey: 

servicc-<:ategoiy: 
opaque: 

type: 

server-date: 
25 swversion: 

instrument-number: 
instrument-type: 
in^rument-categoiy: 
instrument-functions: 
30 instrument-salt: 
mstrument-naniei 
instrument-street: 



brianb-23 
2277053 

19951125100510589 

CClOOl 

admin 

h md - inst i ^ it ne nt 

199S1125100S12689 

l.Owin 

059013218175654 

dda 

dda 

load, unload 
4bmii8poetqv=: 
Brian Q. Brian 
100 Elm Street 
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instniment-city: Nice Place 

instrument-state: VA 
instrument-postal-code: 00000 
instrument-country: USA 
agreements: 75.123 
autociose: yes 
autoclose-passphrase: badnews 
key: 4/Roos+2ac8 = 

signature: sjadUcaslzfelksajzlffeUcsajd 

jzIffeUcsajzlffzBcsajzl^ 
7hgfce/juy +poiuhnbvcdewqazxp 

Server computer creates a new record 140.2 in server message log 140 
and saves a copy of message BIl in field 140E. Server computer 100 then unwraps 
15 message Bn and processes it as previously described and updates record 140.2 of 
server message log 140 as follows: 

persona-id: brainb-23 
session-id 

20 transaction-number: 2277053 
index: 

incOTning-message: copy of BIl 
response-message: 



25 



Server conqiuter 100 then updates server persona data structure 
120.1 for persona "brianb-23- by entering "badnews" into die autociose passphrase 
field 120F and byadding instrument binding data to field 120H as foUows: 



persona-id: 

30 instrument-type: 
Instrument-mmiber: 
Instrument-native currency 
Instnmoent-preflx: 
Legal-agreements: 

35 Instrument-hash: 

Issuer-identification number: 
Instrument-holder-name: 
Instrument-holder-address: 
Instrument-bind-date: 

40 Instrument-first-used-date: 
Binding-status: 
Sale-transaction-enabied: 
Sale-tranraction-limiL* 
Credit-transaction^enabled: 



brianb-23 
dda 

aswerfcvg [encrypted] 
usd 

055654 
75,123 

uou980y57rd98jnhgt54c3 = = 
735980 

lkpq)oipoi [encrytped] 
oipipoipipo [encrypted] 
19951125100513583 

created 
no 

no 
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Credit-transaction-limit: 
Load-cash-^eoabled: 
Load-cash-traDsacdon limit: 
Uaload-casb-enabled: 
Unload-cash-transaction limit: 
Autoclose-binding : 



yes 

usd 1000.00 

yes 

-1 

yes 
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Server computer 100 then assembles message BI4, saves a copy of it in 
field 140F of record 140.2 of server message log 140, and sends message BI4 to 
customer user 203. Message BI4 contains the following: 



15 



20 



25 



30 



35 



40 



persona*id: 

transaction-number: 

date: 

service-category: 
opaque: 

type: 



serverKiate: 

response-code: 

swseverity: 

swnaessage; 

instrument-number: 

instrument-type: 

instrument-issuer: 

instrument-issuer-countxy: 

mstiument-funcdons: 

instimnent-type : 

instrument-issuer: 

instnmient-issuer-country: 

instrument-functions: 

instrument-salt: 



bnanb-23 
2277053 

19951125100510589 
admin 

bind-instrument-response 

19951125100513583 

success 

wa rning 

New software is available. 

059013218175654 

dda 

East Bank of the Mississippi 
us 

load, unload 

059013218175654 

dda 

EastBank of die Mississippi 
us 

load.unload 
4bmn8poetqv'» 



Customer conqniter 200 unwr^ message BI4 and processes it as 
previously described, then iqxlates record 220.1 in customer posona data strucmre 
220 for persona "brianb-23'' by adding instrument binding data to field 220J as 
follows: 



persona-id 

instrmnent-numben 

instrument-description: 

holder-name: 

holder-address: 

holder-city: 



brianb-23 
059013218175654 
my fun account 
Brian Brian 
100 Ehn Street 
Nice Place, VA 
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holder-country: 

hoIder-postal*code: 

holder-country-code : 

holder-area-code: 

holder-telephone: 

currency: 

transact-sale-flag: 

transact-credit-flag: 

unload-fiinds-flag: 

load-fiinds-flag: 

status: 

instrument-recurring-data: 



15 



20 



agreements: 



USA 

00000 

1 

703 

555-1212 

usd 

no 

no 

yes 

yes 

approved 

instrument-number:059013218175654 1 instniment- 
type:dda | instniment- 

issuer:EastBankoftheMississippi | instrumen 
t-issuer-countiy :us | instniment- 
functions:load,unload | instrument- 
saIt'4bnm8poetqv 

75,123 



C> Load/imlA^^ Proce ss 405 

Load/unload process 405 begins when customer user 203 selects the 
load operation ftom customer appUcation software 210. Customer application 
software 210 then prompts customer user 203 for the instrument from which to load 
25 fiuKis to persona brianb23. Customer user 2ra 

prompted for the amount to be transferred. In response to a prompt for the amount 
customer user 203 enters $100.00. Customer appUcation software 210 then assembles 
niessageLUl as previously described and sends it to server OT^^ Message 
LUl contains the following information: 



30 



35 



40 



id: 

transaction-number 
date: 

serverkey: 

service-category: 
opaque: 

type: 

server-date: 

amount: 

key: 

signature: 



brianb-23 
2277054 

19951105103517688 

CClOOl 

cash 

load-unload-funds 
19951105103519788 
usd 100.00 
4/Roos+2ac8= 

Ujwhjwlimceiwlcegdwewleiciwlcefidwewl 
eiciwlcefjdwcwleicjwlierqiqhodqhoiwehqx 
q23jioerpoiuklhgrqwer7y6tghjuiko09p+po 



159 



9ijhtSie3wx 

Server conyniter creates a new record 140.3 in server message log 140 
and saves a copy of message LUl in field 140E, Server computer 100 then unwraps 
5 message LUl and processes it as previously described and updates record 140.3 of 
server message log 140 as follows: 

persona-id: brainb-23 
session-id: 

10 transaction-number: 2277054 
index: 

incoming-message: copy of LUl 
response-message: 

15 Server computer 100 then updates customer persona record 
120.1 by adding cash container data to field 120G as follows: 

Currency: usd 

Available-balance: 100.00 

20 On-hold-balaiK:e: 0.00 

Agency-account-number. 113317834 



in field 140E of record 140.3 of server message log 140, and transmits message LU2 
25 to customer computer 100. Message LU2 contains the following infonnadon: 



Server computer 100 then assembles message LU2, saves a copy of it 



id: 

transaction-number: 
date: 

service-category: 
opaque: 



brianb-23 
2277054 

19951105103517688 
cash 



30 



40 



35 



type: 



server-date: 

amount: 

response-code: 

message: 

swseverity: 

swmessage: 

fiee: 

balaiK:e: 

session-fmKls: 

on-hold: 



load-unload-response 

19951105103607914 

usd 100.00 

success 

funds-loaded 

warning 

New software is available, 
usd 0.0 
usd 100.00 
usd 0.00 
usd 0.00 
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Customer computer 200 unwraps message LU2 and processes it as 
previously described, then updates record 220.1 in customer persona data structure 
220 for persona "brianb-23" by entering "usd 100" into cash container field 220J, 
IL Open Session Process 407 
5 Create session process 407 begins when customer user 203 selects the 

open session operation from customer application software 210. Customer application 
software 203 then prompts customer user 203 for the following information: desired 
session lifetime in minutes; maximum number of transactions to be conducted during 
session; the amamt of funds to be available during the session; and a memo 
10 describing the session. 

In response to a pronq)t for the desired lifetime of die session in 
minutes, customer user 203 enters "120*. In response to a prompt for the maximum 
number of transaction to be conducted during the session, customer user 203 enters 
"25". In response to the prompt for the amount of funds to be available during the 
session, customer enters "70.00". In response to a pronq)t for a memo describing the 
session, customer user 203 enters "Christmas shopping spree. " 

Customer 200 then assembles a message OSl aiKl sends it to server 
computer 100. Message OSl includes the foUowing information: 

id- brianb-23 
transaction-number: 2277055 
date: 19951105104131914 
serverkey: CClOOl 
service-category: cash 
opaque: 

type* open-session 
server-date: 19951 105104134014 

swversion: l.Owin 
record-note: Christmas shopping spree 

amount: usd 70.00 

key-lifedme: 0120 
k^-uselimit: 25 
toy: 4/Roos+2ac8= 

signature: Icasdjflasjdzuoi579384ng09kdfgj09eurtndfb 

nb909nlktujwjsi86tjf9086ptjfgr6jir46edclop 
laszxewqnym +09uhgtr432zxcvbhgrewql2r 
gSmkoOI 

Server compute creates a new record 140.4 in server message log 140 
and saves a copy of message OSl in field 140E. Server computer 100 then unwraps 
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1 

j 

message OSl, processes it as previously described, and updates record 140.4 of I 
server message log 140 as follows: j 

i 

persona-id: braiiib-23 I 

5 session-id: i 
transaction-number: 2277055 1 

index: 

incoming-message: copy of OSl 

response-message: 

10 

Server conq)uter 100 then creates a record 130.1 in server 
session data structure 130 associated with persona id "brianb-23". Record 130.1 
contains the following information: 



15 


iSession-ID: 


J/Pi+sqGtgH= 




Session-Key: 


7ujm8ilctgTRrfv3edc9olk= = 




Session-Salt: 


aa5yh8fdkl+ = 




Currency: 


usd 




Opening-Am<Muxt: 


70.00 


20 


Current-Anoount 


70.00 




Opening-Date: 


19951105104137179 




Qosing-Date: 






Key-Use-limit: 


15 




Key-lifetime: 


0060 


25 


Persona-ID: 


biainb-23 




Status: 


open 




Memo: 


Christmas shopping spree 




Transaction-data: 





30 Server computer 100 also updates record 120-1 m server persona data 

structure 120 associated with persona ''brianb-23" by deducting the amount "70.00* 
from the amount "100.00" from tiie available balance field 120G.2 of die cash 
container previously described. Server computer assembles a message 0S2, saves a 
copy of it in field 140F of record 140.4» and transmits message OS2 to customer 

35 computer 200. Message 0S2 includes the following information: 

id: brianb-23 

transactioii: 2277055 

date: 19951105104131914 

service-category: cash 
40 opaque: 

type: open-sessionrre^nse 

server^daie: 19951105104137179 
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reqx}nse<ode: 

swseverity: 

swmessage: 

key-lifetime: 

key-uselimit: 

amount: 

foreign-exchange: 

session-funds: 

balance: 

on-hold: 

fee: 

session-id: 

session-key: 

session-salt: 



success 
warning 

New software is available. 

0060 

15 

usd 70.00 

cad 0.60 gbp 1.55 

usd 70.00 

usd 30.00 

usd 0.00 

usd 0.00 

J/Pi+sqGtgH= 

7ujm8iktgTRrfv3edc9olk= = 

aa5yh8fdkl+ = 



Customer conqmter 200 unwraps message 0S2 and processes it as 

previously described, dien creates a new record 240.1 in customer session data 

structure 240 associated with persona "brianb-23" as follows: 

Session-ID: 
Session-Key: 
Session-Salt: 
Currency: 
Opening- Amount: 
Current-Amount 
Opening-Date: 
Key Use-limit: 



Key-lifetime: 
Memo: 



J/Pi+sqGtgH= 

7ujm8iktgTRrfv3edc9olk= = 

aa5yh8fdkl+ = 

usd 

70.00 

70.00 

19951105104137179 
15 



0060 

Christmas shopping spree 
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The process whereby merchant user 303 opens a session is the same 
except that a merchant will not transfer funds from its persona cash container to a 
session register. This is because a merchant expects to receive funds and does not 
need funds available to it during a selling session. Server computer 100 creates a 
record 130.2 in server session data structure 130 associated with merchant user 303*s 
persona "acme-n* as follows: 



sessioiK-ID: 
session-key: 
session-salt: 
.40 currency: 

opening-anKRmt: 

current-anxnmt: 

opening-date: 



k/iL+tpPmHg= 

3ejkPOM7T+poBQW9ipqwZ8= 

qw89Ik3vAZ= = 

usd 

0.00 

0.00 

110595063012147 
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closing-date: 

key-use-Iimit: 

key-lifetime: 

persona-ID: 

status: 

memo: 

transaction-data: 



090 
0960 
acme-12 
open 

shoe department sales 



10 



15 



20 



25 



30 



35 



40 



Upon opening a session, merchant computer 303 creates a new 
record 370.1 in merchant cash log data structure 370 as follows: 



type: 
status: 

transaction-number 

requested-session-duration: 

requested-sessioo-count: 

session-id: 

result-code: 



open-session 
open 

55443322 

0960 

90 

k/iL+q>PmHg= 
access 



TYi^m:^^'^ Payment Process 409 
Transaction payment process 409 begins when customer user 203 
responds to an offer from merchant user 303 to sell rocket shoes under specified 
terms by selecting "cash payment" as the mechanism for payment This act causes 
merchant computer 300 to assemble message PRl and transmit it to custonner 
computer 200 as previously described. Message PRl includes the following 
information: 



type: 

merchant-ccid: 

merchant-order-id: 

merchant-date: 

merchant-swversion: 

ix>te: 



merchant-amount: 
merchant-amouni2 : 



payment-request 
Acme-12 

1231-3424-234242 

19951105104536378 

foo69 

ACME Products 

Purchase of 1 pair "Rocket Shoes" at 
$37.50 ea. 

Shipping and iignrititig $5.00 
Total Price: $42.50 
Ship to: 

Brian Brian 

100 Ehn Stre^ 

Nice Place, VA 00000 USA 

usd 42.50 
cad 54.25 
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accepts: 

url-pay-to: 

iirl<ancel: 

uri-success: 
url-fail; 

merchant-signed-hash-Icey: 
meichant-signed-hash: 



visa; master; amex; JCPenny; macy 
ht5>://www,ACME.com/ServerPaymem 
http://www.ACME.coin/CyberPayinem 
Cancel 

http://www. ACME, com/ordersuccess 
http://www.ACME.com/onlerfail 
ISLzs/vFQ0BXfU98LZNWhQ= = 

kigikdfgUcdfsutlcdgglds7503qwrtjtyuvnvidurO9 

e5gfdj9086jCS985kf9086kg9894j6g- 

t094543jvndmkzazqpl 



Merchant computer 300 also creates a new record 350.1 of merchant 
amount data structure 350 as follows: 



order-id; 

amount-of-transaction: 
flag: 



1231-3424-234242 
usd 42.50 
pending 



Customer computer 200 processes message PRl as previously 
descnbed. In response to a prompt from customer application software 210, 
customer user 203 indicates its acceptance of the offer of merchant user 203 by 
selecting "pay cash". This act causes customer computer 200 to assemble message 
CAl and transmit it to merchant computer 300. Message CAl inchides the following 
information: 



type: 
version; 
session-id: 
index; 

payee-currency: 

note-hash: 

payee-id: 

order-id: 

service-category: 

opaque: 

amount: 
auth-code: 



cash-payment 
1 

J/Pi+sqGtgH=: 
1 

usd 

tyrioldjhgbvxczm7rfde4= = 
acme-12 

1231-3424-234242 
cash 

usd 42.50 

iou234rfgvbmcxp+poliu7= - 



Mercham computer 300 processes message CAl as previously 
described. Merchant computer 100 then assembles message CA2 as previously 
described and transmits it to server computer 100. Message CA2 inchides the 
following information: 
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1 

kyiL+tpPmHg= = 
77 
cash 

cash-collection 
1 

Cash-payment 
1 

J/Pi+sqGtgH= 
1 

kchfiZ5WAUIpkl/vlogwuQ= = 
Acme-12 

1231-3424-234242 
usd 42.50 

UjlcHgtK/38uhzxs9io3 +PL= = 

jksyfditdflcigdfulO29}f9q087SjCSjmg^ 

fin9345kdkiijghnvrofliazapiak5dijdfl^^ 

pStzewqasz 

Merchant computer 300 iqxlates record 370.1 of merchant cash log 
data structure 370 by addmg die following additional data to die existing record (all 
of record 370.1 is shown for clarity): 



version; 
session-id: 
index: 

service-category : 
5 merchant-opaque: 
type: 
version: 
type: 

subversioDo: 
1 0 payer-session-idg: 
payer-index^: - 
note-hash^: 
payee-id„: 
order-id^: 

15 merchant-amountB: 
autb-code: 
customer-opaque: 



25 


type: 


cash payment 




status: 


pending 




order-id: 


1231-3424-234242 




customer-session-ID: 


J/Pi+sqGtgH= 




customer-index-number: 


1 


30 


customer-currency: 


usd 




merchant-session-ID: 


lc/iL+tpPmHg= 




merchant-index-number: 


77 




merchant-curreiKy: 


usd 




merchant-amount-requested: 


42.50 


35 


amount-credited: 


42.50 




fees-paid: 


0.00 




type: 


open-sessi(Hi 




status: 


open 




transaction-number: 


78765437 


40 


requcsted-session-duraticm: 


0960 




requested-session-count 


90 




session-ID: 


Ic/iL+tpPmHg= 




result-code 


success 



45 



Server computer creates a new record 140.5 in server message log 140 
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and saves a copy of message CA2 in field 140E. Server computer 100 then unwraps 
message CA2, processes it as previously described. Server computer 100 checks 
records 130.1 and 130.2 of server session data strucmre 130 to determine if both 
persona brianb-23 and persona acme- 12 have open sessions. If a session is invalid, 
5 server computer terminates t=action payment process 409. Here, server computer 
100 proceeds and updates record 140.5 of server message log 140 as follows: 
persona-id: acme-12 
session-id: lc/iL+tpPmHg= 
transaction-number: 
10 irxiex: 77 

incoming-message: copy of message CA2 

response-message 

Server computer also iqxlates record 130. 1 of server session data 
15 structure 130 by associating die following information with transaction data field 
130N: 

amount: usd 42.50 

customer-session-id: J/Pi +sqGtgH - 

merchant-onler-id: 1231-3424-234242 
2 0 merchant-persona-id: acme-12 
customer-index: 1 

Server computer also updates record 130.2 of server session data 
structure 130 by associating the following information with transaction data field 
25 BONN: 

amount usd 42,50 

custtHner-session-id: J/Pi+sqGtgH= 

merchant-order-id: 123 1-3424-234242 

merchant-persona-id: acme-12 

30 merchant-index: 77 

Server computer 100 then assembles message CA3 aiHl transmits it to 
merchant conqniter 300 as previously described. Message CAS includes die 
foUowixig information: 

35 type: ftom-server 
versiorr 1 

sessi<m-id: lc/iL+q)PmHg= 

index: 77 

service-category: cash 
4 0 merchant-<q)a([ue: 
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subtype: 


cash-batch-receq)t 


subversion: 


1 


request-version: 


1 


response-code: 


success 


fee: 


usd 0.00 


subtype„: 


cash-payment-receipt 


subversion^: 


1 


payer-session-id„: 


J/Pi+sqGtgH- 


payer-iodexQ: 


1 


iesponse-code„: 


success 


collected-amount^: 


usd 42.50 


order-id^: 


1231-3424-234242 


auth-code: 


pl2P+/BNfr59dsXz+lmmTP= = 


[ue: 




service-category: 


cash 


response-code: 


success 


amount: 


usd 42.50 


order-id: 


1231-3424-234242 


autb-code: 


kiTUY7f7zr+pGB65RXE+hc= = 



Merchant computer 300 unwraps message CA3 and processes it as 
previously described. Merchant computer 300 updates record 350. 1 of merchant 
amount data structures 350 by setting flag field 350C to "paid*. 

Merchant conqmter 300 updates record 370.1 of merchant cash log 
data structure 370 as follows: 

Stams field 370B is set to "success". Amount credited field 370K is 
set to "usd 42.50". 

Merchant computer assembles message CA4 and transmits it to 
customer computer 200. Message CA4 includes the following information: 



type: 

version: 

session-id: 

service-category: 

index: 

order-id: 

opaque: 



cash-payer-receipt 
1 

k/iL+tpPmHg= 

cash 

77 

1231-3424-234242 



40 



response-code: 
amount: 
order-id: 
audHcode: 



success 
usd 42.50 
1231-3424-234242 
mhgD4QaBPIg + vWlciHytR5J= ^ 



Customer computer 200 unwraps and processes message C A4 as 
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previously described. Customer computer 200 updates record 240. 1 of customer 
session data structure 240 by deducting "$42.50* from current amount field 240F 
leaving a balance of $27.50. 

H Close Session Ptocess 41^ 

Close session process 411 begins when customer user 203 chooses the 

close session prompt from the display on customer computer 200. This act causes 

customer computer 200 to assemble message CSl and transmit it to server computer 

100 as previously described. Message CSl inchides the following mformation: 

brianb-23 
2277056 

19951105110223666 
CClOOl 
cash 

close-session 
19951105110225766 
l.Owin 

J/Pi+sqGtgH= 
No 

4/Roos+2ac8= 

kasdjfaskadnfiwd^iniifcsdnzlskdSOSdipodsi^ 
jg4eazqer98jfejotudQi98ytnmvcxzaqw23rgtylf>mklolq 
azxsw34rfvgy +09okiju7yfanbg 



id: 

transaction: 
date: 

serverkey: 

service-category: 

opaque: 

type: 

server-date: 

swversion: 

session-id: 

request-log: 

key: 

signature: 



25 



35 



Server conqmter creates a ww record 140.6 in server message log 140 
and saves a copy of message CSl in field 140E. Server conDjHiter 100 dien unwraps 
message CSl, processes it as previously described, and updates record 140.6 as 
follows: 

brainb-23 
2277057 
copy of CSl 



persona id: 
30 session id: 
transaction: 
ixKiex: 

incoming-message: 
response-message: 



Server computer 100 flicn updates record 130.1 in server session data 
structure 130 associated with persona id "brianb-23" by adding the value in current 
amount field 130F ($27.50) to die amount in die available balance field 120G.2 of the 
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cash container previously described for a balance of $S7.50» by entering the value 

"19951105110301999'' into closing date field 130H, and by changing status field 

130L from "open" to "closed" and. 

Server computer assembles a message CS2. saves a copy of it in field 

5 140F of recoied 140.6, and transmits message CS2 to customer computer 200. 

Message CS2 inchidesthe following infonnation: 

id: brianb-23 

transaction: 2277057 

date: 19951105110223666 

10 service-category: cash 
opaque: 

type: close-session-response 

server-date: 19951105110301999 

response-code: success 

15 swseverity: warning 

swmessage; New software is available, 

fee: usd 0.00 

amount: usd 27.50 

20 Customer conqaiter 200 unwraps and processes message CS2 as 

previously described. Customer computer 200 iqxlates field 2201 of record 220.1 of 
customer persona data structure 220 by adding $27.50 to die current vahie of field 
2201 ($30.00) for a balance of $57.50. Customer computer 200 deletes record 240.1 
of customer session data structure 240. 

25 While the foregoing description of the present invention has been given 

as an example, it will be appreciated by those of ordinary skill in the art that various 
modifications, alternate configurations and equivalents may be used without departing 
from the scope of the present invention. 
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Claims: 

' I. A method for securely communicating in a conunuoication system, 

wherein the communication system has a device at a user's location and a server in 
5 commimication therewith, wherein the method comprises transmitting a request from the 
device to the server for creating a session having use parameters associated therewith, 
encrypting a first key with a second key by the server, transmitting said encrypted first 
key and said use parameters associated with saicl session from the server to the device, 
receiving said encrypted first key and said use parameters by the device and decrypting 
10 said encrypted first key so that the device can communicate securely in the 
communication system by using said decrypted first key according to said use 
parameters. 

2. A method as claimed in claim 1, wherein said first key is a DES key. 

15 

3. A method of as claimed in claim 1 or 2, wherein said second key is a 
DES key. 

4. A method as claimed in claim 1, wherein said secure communication is 
20 at a security level greater than DES. 

5. A method as claimed in any one of the preceding claims, further 
con^)rising a secood device at a secoixl user's location wherein said second device is 
also in conmounication with the user's device and the server aixi wherein the method 

25 further comprises transmitting a second request from die second device to the server for 
creating a second session having second use parameters associated therewith, encrypting 
a third k^ with a fourth key by the server, transmitting said encrypted third key and 
said second use parameters from the server to the second device, receiving said 
encrypted diiid key and said second use parameters by die second device and decrypting 

30 said third key so that the second device can communicate securely in the conmiunication 
system by using said decrypted third key according to said second use parameters. 
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6. 



A method as claimed in claim S, wherein said third key is a DES key. 



7. A method as claimed in claim 5 or 6, wherein said fourth key is a DES 
key. 

5 

8. A method as claimed in claim 5, wherein said secure communication is 
at a security level greater than DES. 

9. A method as claimed in any one of claims S to 8, further comprising 
10 transmitting a first set of data from the user's device to the second device, wherein said 

first set of data inchides an encrypted portion aiul an unencrypted portion, wherein said 
encrypted portion is encrypted using said decrypted first key and at least a portion of 
said unencrypted portion of said first set of data, receiving said first set of data by the 
second device aiKl transmitting a second set of data together widi said encrypted portion 

15 of said first set of data from the second device to the server, wherein said second set of 
data inchides an encrypted portion and an unencrypted portion, wherein said exxrrypted 
portion of said second set of data inchides at least a portion of said imencrypted portion 
of said first set of data, and wherein said encrypted portion of said second set of data 
is encrypted using said decrypted third key and at least a portion of said unencrypted 

20 portion of said second set of data, and receiving said second set of data transmitted from 
said second device by tte server and decryptiog said encrypted portion of said second 
set of data using said third key axxl said portion of said unencrypted portion of said 
second s^ of data so tibat said portion of said first set of data inchided in said encrypted 
portion of said second s^ of data is decrypted, and decrypting said encrypted portion of 

25 said first set of data usiiig said first key and said portion of said decrypted portion of 
said first set of data, so that the user is verified by die server using said first key aiKi 
the second user is verified by the server using said third key. 

10. A method of securely conununicating in a communication system, 
30 substantially as herein described, with reference to the accompanying drawings. 
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